Our discussion in this chapter centers on an ordered list class, in which the elements of the list are integers, and the list is maintained in ascending order. Listing 13.1 contains the method signatures for this class (written in Java). This simple class contains several categories of relatively standard methods, as follows:
Listing 13.1 Method signatures for the ordered list classpublic class OrderedList { public OrderedList() {} public boolean member(int v) {...} public OrderedList add(int v) {...} public int head() {...} public int length() {...} public boolean equals(OrderedList list) {...} public OrderedList tail() {...} public OrderedList delete(int v) {...} } It is possible to identify a large number of test cases for this class. We design test cases as assertions on the relationship between objects produced by the various list methods. This is a relatively common XP practice because it supports test automation [Beck2000; Beck+1998]. Table 13.1 contains a set of test cases for this class written as Java assertions, sometimes preceded with additional Java code. We do not claim that these test cases constitute adequate testing for this class; our interest here is simply to define a large enough set to be interesting for a discussion of the micro-incremental testing process. (Note that Table 13.1 uses the notation "<1,2>" to denote a list consisting of 1 as the first element and 2 as the second element. Also, Create is a method external to OrderedList that invokes the OrderedList constructor to generate a new, empty list object.) This method is used for the expository purpose of brevity.
In the rest of the chapter, we use this example (both the ordered list class and associated test cases) to explore our two process models for conducting micro-incremental testing. The next section contains a relatively ad hoc model, while the model of the following section involves more extensive test planning before coding. To clarify the subsequent discussion, we define some basic testing terminology that is consistent with the development cycle discussed previously. We say that a test run is the actual execution of a test case. Test runs are said to be expected-positive whenever it is expected that they will run properly (that is, after the methods have been implemented). Test runs are said to be expected-negative whenever it is expected that they will not run properly (that is, in the second phase, before the methods have been implemented). A test run is said to be successful if its goal is met. That is, an expected-positive test run is successful if it does not reveal a defect; an expected-negative test run is successful if it does reveal a defect. A test run is feasible if it is possible to achieve success when executed, and infeasible if it is impossible to achieve success. For example, if one or more methods referenced by a test case have not been written yet, an expected-positive test run of that test case is infeasible. |