- this one is also obvious, but new features and new bug fixes should
have unit tests
-- in an ideal world we'd do test-driven development (TDD) which would
help us have cleaner code, less code, and tighter APIs
-- if we're not doing TDD, we should at least aim to write tests
immediately after bug fixes or feature work
+1!
If at all possible, write the test that showcases the bug, THEN fix it.
That way you have a nice traffic light to prove you fixed it.
Also, for the case of accepting patches from the community -- ask for a
JUnit to reproduce the problem. That way you not only get a free test
for the suite, but you increase the LOC from contributors who may one
day become committers. Unlike a patch which may be impossible for an end
user to write or may not be exactly optimal (because contributors aren't
always as intimate w/ the code as committers), a JUnit is probably fine
to accept verbatim, which gives the contributor the immediate warm glow
of having helped.
$0.02,
--
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash CBI
_______________________________________________
linux-distros-dev mailing list
linux-distros-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linux-distros-dev
