On 01/31/2013 12:12 PM, Kris Borchers wrote:
I want to throw this out to the list for feedback. Something we have
been doing for a while now with the jQuery project is to require a unit test(s) for any PR
or change committed. This has worked very well in two ways. First, it provides a built in
way to see the issue being fixed/implemented within the PR. That way, the reviewer
doesn't have to build their own test(s) to see if the issue being addressed is
actually fixed. Second, it helps prevent regressions down the road since more of the code
is covered by tests so you know if some change you think is unrelated breaks something
that fixed days, weeks, years ago.
I would like to suggest we make this policy for at least the JS library (since that is
the one I review most often) but I believe this policy would be useful across the entire
project. Let me know what you think.
On the one hand I really REALLY appreciate good
testing. If your code
is easy to write tests for it is (in theory) easy to use. Otoh I REALLY
hate writing tests for obvious implementations/impossible scenarios just
to get coverage.
(ex In Java land obvious is getter/setters and an impossible scenario
would be catching UnsupportedEncodingException for
String.getBytes("UTF-8").)
Thanks,
Kris
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev