This article is based on The Art of Unit Testing, to be published in May 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.

Duplication in our unit tests can hurt us as developers just as much (if not more) than duplication in production code. The DRY (Don't Repeat Yourself) Principle should be in effect in test code as if it were production code. Duplicated code means more code to change when one particular aspect we test against may change. Changing a constructor, changing the semantics of using a class, and more, can have a large effect on tests that have a lot of duplicated code.

To understand why, let’s begin with a simple example of a test, seen in listing 1.

What’s wrong with the tests in listing 2? The main problem is that if the way they use LogAnalyzer change (its semantics), the tests will have to be maintained independently of each other, leading to more maintenance work. Here’s an example of such a change in listing 3:

Now, the two tests that we’ve written will both break, because they both neglect to call Initialize() against the LogAnalyzer class. Because we have code duplication (both of the tests create the class within the test) we need to go into each one and change it to call initialize() first.

We can refactor the tests to remove the duplication of creating the LogAnalyzer into a single CreateDefaultAnalyzer() method which both tests will call. We could also push the creation and initialization up into a new [setup] method in our test class.