But TDD isn't everywhere and the truth is that there must be reasons for that. Good reasons. Clearly, I need to read, talk to people and think deeper about the Whats, Whys and Hows of TDD.
This series haphazardly documents some of that journey.
TDD is an attempt to control the gap between decision and feedback
When you 1) acknowledge the existence of the gap between decision and feedback and 2) decide to accept responsibility for the size of the gap, you begin to look for strategies that can control the gap. In some situations, TDD is an appropriate method of gap control.
Source: Test-Driven Development by Example (page xii)
TDD is motivated by engineering principles
As one commentator notes, TDD seeks to give answers to questions that are motivated by fundamentally sound engineering principles:
Am I on the right track?
Did I break existing functionality?
How quickly and frequently can I get answers to the above two questions?
Source: A forum post on ycombinator
TDD won't always be an appropriate strategy
In some situations, TDD is an appropriate strategy. Conversely, TDD isn't an appropriate strategy in all situations. TDD isn't appropriate when:
you cannot predict inputs to outputs
you cannot guess some of the important test cases
you cannot run a micro-test to gain confidence about macro-results
you cannot write tests with acceptable qualities
Source: Two articles by Kent Beck (see the links)
Conclusion
TDD isn't the point of TDD. Instead, it is a specific practice that tries to address and control the gap between decision and feedback.
One of the values TDD contributes (whether the situation makes it an appropriate strategy or not) is that familiarity with it encourages an engineering mindset: professionalism and accountability about the consequences of decisions.
Although TDD won't always be appropriate, this underlying mindset will be.