"Martin P. Hellwig" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list