Test-driven design (was: Comparing Dictionaries)

[Ben Finney]

"Martin P. Hellwig" <mhellwig at xs4all.nl> writes:

> But the funny thing that I have seen in the development scene is
> that writing tests first and code later is a lot easier when you
> have a technical specification to base it on. A technical
> specification is of course based on a functional design. A
> functional design is written on the base of the assignment and the
> scope definition.

This is, to my mind, one of the greatest advantages of test-driven
development: if you're not clear on how the code will be used, you
can't write the test, and (by the discipline of TDD) you can't write
the code either.

Therefore, you're forced to confront the fuzziness of your design
*before* it causes you to write meaningless code – but only to the
extent necessary to write the code at hand. If understanding the code
you're about to write requires some more extensive design thinking,
that's all to the good; but if you have enough understanding to write
a test for the small area you're on, you don't need to do a huge
amount of design. The stark confrontation of needing to write the unit
test up front shows you the difference, at exactly the time it's most
useful.

There are many who call TDD "test-driven design" for this same reason.

-- 
 \         "A child of five could understand this. Fetch me a child of |
  `\                                           five."  -- Groucho Marx |
_o__)                                                                  |
Ben Finney