Introduction

XP is one of several lightweight software development methodologies. It involves extremely short incremental release cycles, early and frequent testing, heavy use of refactoring, and pair programming [Beck2000]. XP has had early success on its first project [C3Team1998].

Testing is a particularly important part of XP. In particular, XP requires unit testing, with a strong emphasis on early and frequent testing during the development process. XP also requires that test cases be written before coding and (typically) that test cases be written in a form in which they can be automated. A popular testing tool is the JUnit suite for Java [Beck+1998]. This tool eases the execution of unit tests. Its focus is to automate the process and to reduce the amount of manual output checking (that is, GuruChecksOutput, where an expert reads the output of every test run [Farrell2000]).

In previous work [Parrish+1996], we proposed the notion of micro-incremental testing to refer to testing in multiple iterations during the development of a single class. The goal of micro-incremental testing is to reveal defects in the context of the simplest possible collection of methods by testing small numbers of methods first. Micro-incremental testing is consistent with the goals of XP and should be practiced as part of an overall XP methodology.

In this chapter, we present two separate process models for conducting micro-incremental testing. One such model involves developing test cases one at a time in an ad hoc order. As each test case is developed, the methods needed to execute that test case are written, enabling the test case to be executed. This process model is effectively the prevalent testing model in XP and is consistent in its details with the approach proposed in [Beck+1998].

The other micro-incremental testing model involves developing larger sets of test cases and then using a simple, greedy strategy to determine a desirable order in which to develop the methods in those test cases. This strategy attempts to maximize the amount of testing that can occur after each method is developed. Although such a strategy requires some overhead that may not appear to be consistent with the goals of XP, we claim that it is paradigmatically similar enough to the commonly employed ad hoc model that, with tool support, it can be regarded as a legitimate XP testing process model. Although the applicability of this strategy-based approach may be limited in the context of new development, it appears to be particularly useful in the context of refactoring.

We present both of these process models as ways of doing testing that are consistent with the goals of XP. Both have relative advantages and disadvantages, which we also discuss. To make our discussion concrete, our discussion takes place in the context of developing and testing an example ordered list class.

The remainder of the chapter is organized as follows. In the next section, we present our ordered list class along with some test cases that are appropriate for that class. We also define some basic testing terminology needed for the remainder of the chapter. We then present the two testing models, followed by a discussion of their relative applicability to XP.