Joel Hedlund wrote: >> test-driven development merely means that you take that test case and >> *keep it* in your unit test. Then, once you're assured that you will >> find the bug again any time it reappears, go ahead and fix it. > > My presumption has been that in order to do proper test-driven development > I would have to make enormous test suites covering all bases for my small > hacks before I could getting down and dirty with coding (as for example in > http://www.diveintopython.org/unit_testing). This of course isn't very > appealing when you need something done "now". But if I understand you > correctly, if I would formalize what little testing I do, so that I can > add to a growing test suite for each program as bugs are discovered and > needs arise, would you consider that proper test-driven development? (or > rather, is that how you do it?)
Sounds good to me. IMHO there are two ways one gathers tests: - concrete bugs appear, and one writes a test that reproduces the bug & eventually after the fix runs smoothly - new features are planned/implemented, and the tests accompany them right from the start, to allow .. .well, to test them :) I always found it difficult to "just think" of new tests. Of course if you _start_ with TDD, point two is applied right from the start and should apply. Diez -- http://mail.python.org/mailman/listinfo/python-list
