On Jan 31, 2013, at 11:59 AM, Summers Pittman <supittma(a)redhat.com> wrote:
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.
I agree. We should not
write tests just for coverage but instead to test actual bug fixes (not simple typos or
minor things where the solution was obvious) or new features.
(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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev