Andrew Lentvorski wrote: >.. > I have come to the conclusion that the "test first" folks are wrong. > > Write the code to do what you want to do first. > > Write tests as you *debug*. The act of writing the debug tests causes > the refactoring that the "test first" folks so actively crave. > > I find that when I make the shift to the debug phase is when I actually > can start to delineate the boundaries. Before that, it's wasted effort. > > In addition, those areas with the most bugs accrete the most tests. This > is, in fact, what you want. You don't want to spend lots of time > writing tests for areas that you got correct; you want to spend as much > time writing tests for those areas which are tricky. > > Perhaps this breaks down in a group. But when I am writing something by > myself, my time is the single most valuable commodity. I can't afford > to be wasting time writing tests for those areas I got right or for > those areas which are going to get ripped out shortly. >
How much code can one write before starting to test? It depends, of course -- on programmer expertise (strongly), familiarity with the problem, nature of the problem, and probably lots of other things. For some people, in some cases, they can probably complete a component or module or even a small application in a single burst. Maybe even do little/no unit testing, only acceptance testing. It would be wrong to impose an artificially small "coding chunk-size prior to test" just to satisfy some formula. Even in those cases, when undertaking future modification of the code (evolution, bugfixes), even the original coder might well choose to build some unit tests, at least around the internal parts that need changing, before changing anything. You might say that the unit tests get deferred until they provide specific refactoring benefits. On the other end of the scale, I might find myself in some project where I have no great past experience or intimate domain knowledge to call upon. It would be nice to bring in reinforcements, but it's not always possible. Sometimes the design itself is a fits-and-starts process because the requirements are uncertain. Anyway, my point is that I might proceed in fairly small steps -- code-a-little, test-a-little, talk-a-little (with customers, colleagues, domain experts). Writing the tests helps me understand the requirements! Associating tests and requirements also gives me something concrete to base ongoing refinement of the requirements. Witnessing or discussing the tests can even help the customer verbalize and zoom in on what he wants. I certainly don't always write tests before coding, but as the coding steps get smaller, it approximates the test-first practice. Sometimes I write down a few of the (currently in-focus) requirements at the top of the file, as a mini todo list, and make them into tests and then code one requirement at a time. It does help me avoid writing code that does unnecessary things. Oh well, I'm rambling. But the point is that smaller bites may be appropriate for some people, in some cases. .. it depends. There is another general benefit of unit testing that I like to pitch, but I'm having a hard time expressing myself. My observation of my own coding practice is that I have started thinking about design and code structure a little differently. Asking myself "how would I test that", or "what does this do that I can test" leads me, I believe, to better data structures, functions, objects, modular strength -- all those good things. Well, it's not a magic potion, but I'm convinced that thinking about testing makes my code come out smelling better. ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
