TDD and Naming: Part 2

Listen to this post

Tests often establish example values used to compare the behavior of the system with the actual behavior indicated in the requirements. For example, if we had a system behavior that converted a temperature expressed in Fahrenheit to one expressed in Celsius, then the test that specified this might have an assertion along these lines:

assertEquals(100, converter.fahrenheitToCelsius(212));

However the use of these values directly in the assertion sidesteps an opportunity to express the meaning of those values in the specification. Why did we choose 212 and 100, specifically? If there is a reason, then we would want to capture that information as well, in order to form a more complete specification.

The creation of temporary variables, sometimes called “instrumented values” creates this opportunity. For example:

int boilingPointFahrenheit = 212;
int boilingPointCelsius = 100;
assertEquals(boilingPointCelsius, converter.fahrenheitToCelsius(boilingPointFahrenheit));

This not only captures the semantics of the test more completely, but also helps to create the separation of Given/Setup (the instrument is part of this) from the When/Trigger (the calling of the indicated method).

This also makes the test more readable as a specification.

One thought on “TDD and Naming: Part 2”

  1. I appreciate this reminder about using good names to clarify intent. This is simply a basic practice of good software engineering. At a higher level, it seems to me that nearly all good software engineering practices should apply equally to both TDD tests and production code.
    Therefore my question: Are there any Generally Accepted Software Practices (GASP) that do NOT apply to TDD tests? Off hand, I can’t think of any.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.