On Thu, Jan 31, 2013 at 12:59 PM, 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.
(ex In Java land obvious is getter/setters and an impossible scenario would
be catching UnsupportedEncodingException for String.getBytes("UTF-8").)
yup, these things are minor and I am also not to thrilled about adding
tests for that sh**t
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
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf