A tale of caution. In a past life I once advocated strongly for complete coverage on a project. We made it a standard part of the process for each feature 'definition of done'. Eventually, bullshit tests snuck in because of this, and, worse, the suite was terribly slow to run and only getting bigger. The experience left me feeling that coverage is a bit of a ceremony if its not being taken super seriously. (Later we used a fuzzing tool to help shake out bugs and write good/better tests.) It was shitty maintenance that never really contributed to code quality, and because of bullshit tests, in some ways it created LESS quality and harmed our certainty of the suite itself. These days I tend to think that one should write tests to help you write code but only the bare minimum to exercise intent. (And obviously always write a test for every bug filed so no regressions manifest.) Testing is good and maybe coverage useful to understand the weaker areas of code but I would avoid making coverage itself a goal. $0.02 On Fri, Jan 4, 2013 at 11:18 AM, Gord Tanner wrote: > I have been wanting code coverage forever > > +1 > > > On Fri, Jan 4, 2013 at 2:10 PM, Filip Maj wrote: > >> Cool stuff Brent! >> >> +1 >> >> On 1/4/13 10:46 AM, "Dan Silivestru" wrote: >> >> >I'm 100% behind having some sort of code coverage solution in place. >> >Simply >> >counting the number of assertions we have doesn't give us as much >> >confidence as I would like to have. >> > >> >I do somewhat disagree that the node tests are more important the the >> >browser tests. I would at a minimum put them on par since Ripple does run >> >in the browser :-) But I think starting with code coverage for node only >> >is >> >a very good first step. >> > >> >So... long way of me saying... +1 :) >> > >> > >> >On Fri, Jan 4, 2013 at 1:19 PM, Brent Lintner >> >wrote: >> > >> >> Hey all, >> >> >> >> So, I have been using a (recently) new project called CoverJS in one of >> >>my >> >> personal (side projects), and I am finding it really useful and easy to >> >> use/setup when it comes to test code coverage in JS. >> >> >> >> https://npmjs.org/package/coverjs >> >> >> >> My proposal is to add support for test code coverage to Ripple (as test >> >> coverage is something I've really wanted to see go into the development >> >> workflow of Ripple). It is still in some early stages, but I think it >> >>would >> >> be a great project to adopt (even initially) as the code coverage >> >>tooling >> >> for this project. If it it needs to be changed, it should not be too >> >> difficult to rip out or replace, and this does not affect the normal >> >>way of >> >> running tests. >> >> >> >> I.e. Check it out in my fork (first and only commit) --> >> >> https://github.com/brentlintner/Ripple-UI/tree/test.cov >> >> >> >> Since I had already done the setup in my side project, it was quite >> >>easy to >> >> get it working in Ripple (although I had to wait to submit it until an >> >> upstream bug was fixed in CoverJS). The only pitfall here is it >> >>currently >> >> only works when running the tests with the nodejs runner (vs the browser >> >> based test runner, which, IMO is less primary than the node runner, >> >> anyways). However, it is still very useful when testing (even after >> >>using >> >> it a few times). >> >> >> >> Thoughts? Yay/Nay? >> >> >> >> I was hoping to issue a Pull Request soon (if it is a welcomed idea). >> >>:-) >> >> >> >> -- >> >> Brent >> >> >> > >> > >> > >> >-- >> >Dan Silivestru >> >+1 (519) 589-3624 >> >>