Chapter 2 Build a Safety Net

We can learn from our mistakes and get better. Professional developers remedy those quality deficits immediately by fixing the bugs found by QA, and by writing automated unit tests to catch them in the future. Then they should carefully think about this: “How could it happen that we’ve overlooked this issue?” The result of this retrospective should serve as feedback to improve the development process.

Rules for Good Unit Tests

I’ve seen many unit tests that are pretty unhelpful. Unit tests should add value to your project. To achieve this goal, you need to follow some essential rules, which I describe in this section.

Test Code Quality

The same high-quality requirements for the production code have to be valid for the unit test code. I’ll go even further. Ideally, there should be no distinction between production and test code—they are equal. If we say that there is production code on the one hand and test code on the other, we separate things that belong together. Don’t do that! Thinking about production and test code in two categories lays the foundation to neglect tests later in the project.

Unit Test Naming

If a unit test fails, the developer wants to know immediately:

Hence an expressive and descriptive naming standard for your unit tests is very important. My advice is to establish naming standards for all tests.

First of all, it’s good practice to name the unit test module (depending on the unit test framework, they are called test harnesses or test fixtures) in such a way so that the tested unit can be easily derived from it. They should have a name like <Unit_under_Test>Test,

22

Chapter 2 Build a Safety Net

whereby the placeholder <Unit_under_Test> is substituted with the name of the test subject. For instance, if your system under test (SUT) is the unit Money, the corresponding test fixture that attaches to that unit and contains all unit test cases should be named MoneyTest (see Figure 2-3).

Figure 2-3.  The system under test, (SUT) Money and its test fixture, MoneyTest

Beyond that, unit tests must have expressive and descriptive names. It is not helpful when unit tests have meaningless names like testConstructor(), test4391(), or sumTest(). Here are two suggestions for finding good names for them.

For general, multipurpose classes that can be used in different contexts, an expressive name could contain the following parts:

That leads to a name template for unit test procedures/methods like this one:

<PreconditionAndStateOfUnitUnderTest>_<TestedPartOfAPI>_<ExpectedBehavior>

Listing 2-1 shows a few examples.

Listing 2-1.  Examples of Good and Expressive Unit Test Names

void CustomerCacheTest::cacheIsEmpty_addElement_sizeIsOne();

void CustomerCacheTest::cacheContainsOneElement_removeElement_sizeIsZero(); void ComplexNumberCalculatorTest::givenTwoComplexNumbers_add_Works();

23

Chapter 2 Build a Safety Net

void MoneyTest:: givenTwoMoneyObjectsWithDifferentBalance_Inequality Comparison_Works();

void MoneyTest::createMoneyObjectWithParameter_getBalanceAsString_ returnsCorrectString();

void InvoiceTest::invoiceIsReadyForAccounting_getInvoiceDate_returnsToday();

Another possible approach to building expressive unit test names is to manifest a specific requirement in the name. These names typically reflect requirements

of the application’s domain. For instance, they could be derived from stakeholder requirements. See Listing 2-2.

Listing 2-2.  More Examples of Unit Test Names that Verify Domain-Specific Requirements

void UserAccountTest::creatingNewAccountWithExisting EmailAddressThrowsException();

void ChessEngineTest::aPawnCanNotMoveBackwards();

void ChessEngineTest::aCastlingIsNotAllowedIfInvolvedKingHasBeenMovedBefore(); void ChessEngineTest::aCastlingIsNotAllowedIfInvolvedRookHasBeenMovedBefore(); void HeaterControlTest::ifWaterTemperatureIsGreaterThan92DegTurnHeaterOff(); void BookInventoryTest::aBookThatIsInTheInventoryCanBeBorrowedByAuthorized People();

void BookInventoryTest::aBookThatIsAlreadyBorrowedCanNotBeBorrowedTwice();

As you read these test method names, it should become clear that even if the implementation of the tests and the test methods are not shown here, a lot of useful information can be easily derived. This is also a great advantage if such a test fails. All known unit test frameworks either output the name of a failed test via stdout on the command-line interface or list it in a special output window of the IDE. Thus, error location is greatly facilitated.

Unit Test Independence

Each unit test must be independent of all the others. It would be fatal if tests had to be executed in a specific order because one test was based on the result of the previous one. Never write a unit test whose result is the prerequisite for a subsequent test. Never leave the unit under test in an altered state, which is a precondition for the following tests.

24

Chapter 2 Build a Safety Net

Major problems can be caused by global states, for example, the usage of Singletons or static members in your unit under test. Not only do Singletons increase the coupling between software units, they also often hold a global state that circumvents unit test independence. For instance, if a certain global state is the precondition for a successful test, but the previous test has mutated that global state, this can cause serious trouble.

Especially in legacy systems, which are often littered with Singletons, this begs the question: how can you get rid of all those nasty dependencies to those Singletons and make your code more easily testable? Well, that’s an important question I discuss in the section entitled “Dependency Injection” in Chapter 6.

DEALING WITH LEGACY SYSTEMS

If you are confronted with so-called legacy systems and you are facing many difficulties while trying to add unit tests, I recommend the book Working Effectively with Legacy Code [Feathers07] by Michael C. Feathers. Feathers’s book contains many strategies for working with large, untested legacy code bases. It also includes a catalogue of 24 dependencybreaking techniques. These strategies and techniques are beyond the scope of this book.

One Assertion per Test

My advice is to limit a unit test to one assertion only, as shown in Listing 2-3. I know that this is a controversial topic, but I will try to explain why I think this is important.

Listing 2-3.  A Unit Test that Checks the not-equal-Operator of a Money Class

void MoneyTest::givenTwoMoneyObjectsWithDifferentBalance_ InequalityComparison_Works() {

const Money m1(-4000.0); const Money m2(2000.0); ASSERT_TRUE(m1 != m2);

}

One could now argue that you could also check whether other comparison operators (e.g., Money::operator==()) are working correctly in this unit test. It would be easy to do that, by simply adding more assertions, as shown in Listing 2-4.

25