ripple-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Silivestru <dan.silives...@gmail.com>
Subject Re: Test Coverage Tooling in Ripple
Date Fri, 04 Jan 2013 18:46:04 GMT
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 <brent.lintner@gmail.com>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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message