Introduction

"If there is a technique at the heart of extreme programming (XP), it is unit testing" [Beck1999]. As part of their programming activity, XP developers continually write and maintain (white-box) unit tests. These tests are automated, written in the same programming language as the production code, considered an explicit part of the code, and put under revision control.

The XP process encourages writing a test class for every class in the system. Methods in these test classes are used to verify complicated functionality and unusual circumstances. Moreover, they are used to document code by explicitly indicating what the expected results of a method should be for typical cases. Last but not least, tests are added upon receiving a bug report to check for the bug and to check the bug fix [Beck2000].

A typical test for a particular method includes four components: (1) code to set up the fixture (the data used for testing), (2) the call of the method, (3) a comparison of the actual results with the expected values, and (4) code to tear down the fixture. Writing tests is usually supported by frameworks such as JUnit [Beck+1998].

The test code/production code ratio may vary from project to project but is ideally considered to approach a ratio of 1:1. In our project we currently have a 2:3 ratio, although others have reported a lower ratio.^[1] One of the cornerstones of XP is that having many tests available helps the developers overcome their fear of change: The tests will provide immediate feedback if the system gets broken at a critical place. The downside of having many tests, however, is that changes in functionality typically involve changes in the test code as well. The more test code we get, the more important it becomes that this test code is as easily modifiable as the production code.

^[1] This project started a year ago and involves the development of a product called DocGen [Deursen+2001]. Development is done by a small team of five people using XP techniques. Code is written in Java, and we use the JUnit framework for unit testing.

The key XP practice to keep code flexible is "refactor mercilessly": transforming the code to bring it in the simplest possible state. To support this, a catalog of "code smells" and a wide range of refactorings are available, varying from simple modifications up to ways to introduce design patterns systematically in existing code [Fowler1999].

When trying to apply refactorings to the test code of our project, we discovered that refactoring test code is different from refactoring production code. Test code has a distinct set of smells, dealing with the ways in which test cases are organized, how they are implemented, and how they interact with each other. Moreover, improving test code in volves a mixture of refactorings from [Fowler1999] specialized to test code improvements, as well as a set of additional refactorings, involving the modification of test classes, ways of grouping test cases, and so on.

The goal of this chapter is to share our experience in improving our test code with other XP practitioners. To that end, we describe a set of test smells indicating trouble in test code, and a collection of test refactorings explaining how to overcome some of these problems through a simple program modification. This assumes some familiarity with the xUnit framework [Beck+1998] and refactorings as described in [Fowler1999]. We refer to refactorings described in Fowler's book using the format Name (F:page#) and to our test-specific refactorings described in the Refactorings section of this chapter using the format Name (#).