Paul Ort → Influences
Test-Driven Development
What I mean by Test-Driven Development (TDD)
- I view TDD as a practice of making software incrementally, guided by assertions.
- Identifying what change to make: this is the job of the assertion.
- Making the change: this is the job of the implementation.
- Assertion comes first, then implementation.
- Assertions are specifications.
How TDD has shaped how I think about software
- A software system can be understood in terms of its behavior.
- For a given unit of functionality: what truth claims about the system are implied by this functionality, and how can they be expressed in terms that enable evolution of the system into one where these new claims are true?
What are tests in a TDD context?
- falsifiable assertions (demonstrably true or false)
- specifying behavior (establishing requirements)
- driving code changes (realizing requirements)
Why write tests first?
- clarify what is expected of the system
- ensure that only what is necessary is added
- know when the system does not match what is expected
When might TDD not be as useful?
- when exploring rather than specifying
- when the cost of testing is too high
- when there are no conditions to test