Introduction

There is no question that a large body of unit tests adds to overall code quality and developer confidence. In XP, the "burden" of creating unit tests has been placed squarely on the shoulders of developers because of the perception that only a developer can create unit tests. The advantage of this arrangement is that it forces developers to think about how their components are supposed to function, often leading to better code. The disadvantage is that developers may cast a less than critical eye on their code and miss writing robust tests. Writing unit tests, regardless of the ultimate benefit of having them, is a parallel development activity that detracts from the overall amount of time available for developers to write code.

In XP, the role of testers is to collaborate with users to derive and execute acceptance tests. Although a very necessary task, testers are often used less than 100% during the early part of the development cycle while they wait for an end-user interface or a special test-specific user interface to become available. This is often exacerbated by XP's Model First rule, which suggests that developers defer working on the graphical user interface (GUI) as long as possible.

Our goal is to bring testers into the process earlier rather than later, making them an integral part of end-to-end development. Doing so implies moving the responsibility for creating unit and integration-level tests for some parts of the code from developers to testers. Enabling testers to participate in early unit testing tasks accomplishes the following.

• Decreases the amount of time required to develop the full body of test cases that serve as the gateways for new product features.

• Increases the amount of time available for developers to create new functionality and refactor code.

• Makes better use of the QA team earlier in the development cycle.

• Engages testers in validating the implementation, as well as the user interface.

• Brings to bear an impartial set of eyes, experienced in the practice of testing and more critical than the code owners.

• Increases the overall efficiency of the team, leading to greater likelihood of project success.

Involving testers in unit testing does not accomplish the following.

• Alleviates developers of all unit testing responsibilities. It simply adds another set of helping hands.

• Alleviates testers of their acceptance testing responsibility.

• Requires that the testers become developers, although it does provide introductory exposure to code. We have seen several instances of testers whose involvement with unit testing has led them down the development career path.