Listen to this post
TDD, when conducted as a specifying activity, is an aspect of Behavior-Driven Development (BDD). Behavior is what we specify and is what we “drive” into the system using tests. Therefore, when structuring the tests in TDD we can be guided by the language of BDD: Given, When, Then.
Given the system is in a known condition, when an event occurs, then the system should be in the correct new condition.
Any behavior can be specified in this way, and the description is understandable by everyone in the organization because we all grow up learning about the concept of cause and effect.
Where TDD differs, however is that we make this actionable and thus executable. We change the terms accordingly. Some like to use Arrange, Act, Assert, other prefer Setup, Trigger, Verify, etc… but in any case, we turn the nouns of BDD into the verbs of TDD; nothing is “given,” we make it so. We don’t wait for “when,” we do it. We know the “then” because we observe it.
When writing tests in TDD, we take pains to make sure these three different anatomical parts of the test are as distinct and clear as possible to future readers. This includes naming conventions, instrumenting values, and other techniques I will cover in the next few posts.