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

Reply via email to