Nick Boldt wrote:
- 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,
Yeah, we need tests for the bug-fixes.
Please note that in my previous mail about doubts about test-driven
development I was only speaking for implementing new features, not for
bug fixes.
Alex
_______________________________________________
linux-distros-dev mailing list
linux-distros-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linux-distros-dev