[dragonwriter]

> They didn't highlight the key property of a project for when tdd works and when it doesn't: when you know the requirements with clarity (compilers, stacks, etc) it is possible to use tdd since the tests will map back to well understood requirements. But when you don't (like building a website with fussy browsers, or writing a log file parser with format anomalies), you don't have the foresight needed to write the test before the code.

Actually, I think TDD is particularly useful in the last case (writing a log file parser with format anomalies) since you end up with a lot of edge cases where, before you can code to handle each of them, you have to determine exactly what the code should do for each case, often without a clear logical superstructure that explains it all. So you of necessity are incrementally developing a set of test cases before you code to handle each of them -- so if you codify them as automated test cases before you code each, you not only get testing that you handled the new case right, you also get regression that you didn't break the previous ones with the change.

[Walkman]

Kent Beck said the exact opposite, the this particular task cannot easily tested, because you don't know what the input will be.