Joel Hedlund <[EMAIL PROTECTED]> writes: > Do you also do [test-driven development] for all the little stuff, > the small hacks you just whip together to get a particular task > done? My impression is that doing proper unittests adds a lot of > time to development, and I'm thinking that this may be a low return > investment for the small programs.
My impression is that failing to have reliable code adds a lot of time to debugging and maintenance, and it is far cheaper to have tested and flushed out the obvious bugs early in the development process. > I try to aim for reusability and generalizability also in my smaller > hacks mainly as a safeguard. In which case, you will be maintaining that code beyond the initial use for which you thought it up. Maintaining code without unit tests is far more costly than maintaining code with tests, because you have no regression test suite: you are prone to chasing down bugs that you though you'd fixed in an earlier version of the code, but can't figure out when you broke it again. This time is entirely wasted. Instead, in code that has unit tests, a bug found means another unit test to be added (to find and demonstrate that bug). This is work you must do anyway, to be sure that you can actually reproduce the bug; 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 reasoning here is that if I mess up somehow, sooner or later I'll > notice With test-driven development I get much closer to the "sooner" end of that, and much more reliably. > Maybe I should be rethinking this? That's my opinion, yes. -- \ "My mother was like a sister to me, only we didn't have sex | `\ quite so often." -- Emo Philips | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
