Easy ways to maximize the value of TDD

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

About these ads
This entry was posted in TDD. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s