On Fri, Jul 18, 2003 at 01:54:24PM -0700, chromatic wrote: > In general, the person who fixes the bug writes a regression test for > the bug. The pumpkings and other porters are really good about making > sure patches have tests.
Yes, but I'm talking about outstanding bugs that don't have tests yet... > Putting them as TODO tests might just shift the problem -- too many > bugs, not enough people looking at RT to solve them -- into "not enough > people are looking at the TODO tests to solve them". But putting them in the code moves them closer to the pain. Then they're part of the language, rather than one stage removed in a database somewhere. We can also configure things like the smoke test to report on them. If we could mark their severity in some way too, then we could have a better idea of whether or not a new release can happen ... Plus all the usual Test-First reasons to have them before someone writes the patch ... > One idea is attaching a simple test case to every bug report that > doesn't have test code that's nearly right for the core. It's a lot > easier to touch up a test case than it is to write one, so we could do > a lot of good by turning bug reports into executable tests without > having to worry about where they'll eventually end up. I quite like the idea of just annotating the bugs with test cases where applicatable. But I'd prefer to turn them into *real* test cases - not just documented ones... Tony
