Darren New wrote:
David Brown wrote:
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.
I see. Every checkin has to have *more* tests that pass that didn't pass
last time. Very cool idea, especially on a project you know is going to
get big when you start (and which you have some idea of what you want it
to do when you're done). :-)
The extreme programming guys call this "test first".
It's a cool idea, but it rarely works long.
You wind up testing a lot of trivial cases that don't add much to your
test base. They also start taking up lots of execution time.
Eventually, someone needs to go through and separate the tests into
"useful to always run" and "useful to run once in a while."
Of course, nobody wants to do this work. So, the test suite becomes
just as ossified as the main code base. At that point, everybody just
chucks the entire test suite into the "run once a week" bin and defeats
the point of small iterations.
The best solution I've seen is to take a module's entire suite of tests
and move them to the "once a week" category if it hasn't had a bug filed
against it in some number of months.
If a bug pops up, then you pull the tests back into the daily run.
I haven't actually ever tried to implement that. It should be fairly
easy to automate, though.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
