Test-driven design (was: Comparing Dictionaries)
- From: Ben Finney <bignose+hates-spam@xxxxxxxxxxxxxxx>
- Date: Sun, 29 Jul 2007 10:20:59 +1000
"Martin P. Hellwig" <mhellwig@xxxxxxxxx> 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
.
- References:
- Comparing Dictionaries
- From: Kenneth Love
- Re: Comparing Dictionaries
- From: Ben Finney
- Re: Comparing Dictionaries
- From: Kenneth Love
- Re: Comparing Dictionaries
- From: Martin P. Hellwig
- Comparing Dictionaries
- Prev by Date: Re: Events: The Python Way
- Next by Date: Re: Any reason why cStringIO in 2.5 behaves different from 2.4?
- Previous by thread: Re: Comparing Dictionaries
- Next by thread: Re: Comparing Dictionaries
- Index(es):
Relevant Pages
|