Before we’ve made it pass the first time, a failing test tells us what code to write.
When it fails later, it can tell us what we broke. Failing tests alert us to regressions before we integrate.
A test is most valuable when it fails.
This is why the number-one-most-important rule of TDD is to maintain One Logical Assertion Per Test. If you have more than one, a failing test becomes ambiguous. This helps in writing the test and in understanding its failure, also known as diagnostics.
When a test fails you should know exactly why.
Before we’ve written a test we must articulate the rationale behind the whole deal in the first place, and this process helps us reason abut the production system and its design.
After we’ve made it pass the first time, it becomes one in a suite of passing test cases we regularly run. Now it can tell us what the system is doing in a way more understandable than the implementation code.
A test is most valuable when it describes the behavior of the system rather than the implementation.
This is why the number-one-most-important rule of TDD is No Implementation Semantics.
Almost every time I’ve found myself struggling to deliver value with TDD it’s because I’ve failed to follow these two, coequal, number-one-most-important rules: One Logical Assertion Per Test and No Implementation Semantics
