Maintaining the TDD cycle
Reading notes based on Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
This is how the TDD process runs once once it has started.
Start each feature with an acceptance test
The first thing we do when working on a new feature is to write a failing acceptance test. This test demonstrates that the system does not yet have the feature we are about to write. It helps us to track our progress towards the completion of the feature.
IMPORTANT: The language of our acceptance test must not use any underlying tech-related terminology. It should reflect the language of the domain and capture our assumptions of what the system does, not how it will be implemented.
Writing our acceptance tests this way will mean that they will still be valid even if the underlying technologies that we use to build our program changes.
Likewise, writing acceptance tests using the domain language helps us look at the system from our user's point of view based on what they need, instead of seeing through the frosted goggles of the implementation view.
Separate tests that measure progress from those that catch regressions
We expect our acceptance tests to fail until the feature we are testing has been implemented. Passing those tests allows the team to measure the progress they are making. Once they have passed, they should not fail again. A failure here indicates that we have broken our existing code (there has been a regression).
Completed acceptance tests serve a different role to unit and integration tests.
- Acceptance tests (new): Represent work in progress and should not pass until the feature has been complete.