On Fri, Oct 31, 2008 at 04:20:12PM -0700, Darren New wrote:
David Brown wrote:
My previous project made the tests an integral part of the review
process (you couldn't check in a change without a test to demonstrate
that you fixed something. The test had to pass on the current
version, and fail on the previous. An exception had to be explicitly
spelled out and reviewed as well).
Oh, that's a wonderful idea, requiring a previous test to fail. But how do
you implement new functionality? You can't check in a test that fails, and
if the code isn't failing any tests now...
It's not a previous test that fails, but one that you have to write as
part of the existing checkin. In other words, all commits must
include a test that passes, and if the test is run against the current
basline, it must fail.
For the project, doing this was quite a bit of work. We ended up
making the test framework dynamically compile and load the tests so
that they could easily be linked against the previous version. Adding
new functionality usually just failed with a link error.
David
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
