[dwaite]

> Then you, or somebody near you, is doing it very wrong. I do not mean this as a moral judgment, I mean it as an engineering process diagnostic feedback.

IMHO thats the biggest problem with TDD. People often think of TDD as a set of requirements that all push for some set of benefits.

But it is really a development methodology where you as a developer heavily utilize tests to drive the development process itself. It is a mindset, not a checklist.

Perhaps easiest to explain (with an inaccurate comparison) as - it is like REPL-driven development but with persistent and sharable artifacts.

Behavioral driven development is IMHO stronger in this regards, because people tend to understand how the additional artifacts (beyond what you might see with a requirements list or use case document) are part of a methodology. People can better separate the methodology from the benefits/outcome.