Testing Model 1: Ad Hoc Method Ordering


With this model, test cases are written one at a time, without regard to a specific overall ordering of test cases. Then once a particular test case is tested in an expected-negative test run, the methods referred to in the test case are implemented, and the test case is once again executed (this time in an expected-positive test run). Once this test run is successful, the next test case is written, and an expected-negative test run is conducted with that test case. If any of the methods in this test case are not written yet, they are written now, and an expected-positive test run is conducted. In subsequent iterations after the first, it may not be necessary to implement all the methods referred to in that iteration's test case, because some of those methods may have been implemented in a previous iteration.

Assume that n test cases and k methods are in the class under development. We note that the entire set of n test cases may not be known a priori but may very well be developed individually as each is tested. Still, we assume that the total number is finite (n). We can state this model as a relatively straightforward procedure.

For each test case 1 … n:

  1. Write the test case (which references methods mi … mj).

  2. Conduct an expected-negative test run of this test case. Debug the class and repeat this test run until it is successful.

  3. For any method m in mi … mj that has not previously been written, write method m.

  4. Conduct an expected-positive test run of this test case. Debug the class and repeat this test run until it is successful.

We now apply this testing model in the context of our OrderedList class, for which we identified 13 test cases in Table 13.1. As earlier, we do not assume that all these test cases are known a priori. Because our process does not dictate a specific ordering of test case runs in the absence of specific business values, we arbitrarily assume the same ordering as in Table 13.1. We then have the following:

  1. Develop and run test case 1 (assert(Create().add(1).head()== 1);).

    • Write test case 1, which references OrderedList (through Create), add, and head.

    • Conduct an expected-negative test run of this test case. Debug the class and repeat this test run until it is successful.

    • Write these three methods (OrderedList, add, head).

    • Conduct an expected-positive test run of this test case. Debug the class and repeat this test run until it is successful.

  2. Develop and run test case 2 (assert(Create().member(1)== false);).

    • Write test case 2, which references OrderedList (through Create) and member.

    • Conduct an expected-negative test run of this test case. Debug the class and repeat this test run until it is successful.

    • Write the member method. The OrderedList method was already written as part of the testing process for test case 1.

    • Conduct an expected-positive test run of this test case. Debug the class and repeat this test run until it is successful.

  3. Develop and run test case 3 (assert(Create().add(1).tail.equals (Create());).

    • Write test case 3, which references OrderedList (through Create), add, tail, and equals.

    • Conduct an expected-negative test run of this test case. Debug the class and repeat this test run until it is successful.

    • Write the tail and equals methods. The OrderedList and add methods were already written as part of the testing process for test cases 1 and 2.

    • Conduct an expected-positive test run of this test case. Debug the class and repeat this test run until it is successful.

  4. Continue this pattern for test cases 4 through 13.

Given the order of test cases presented in Table 13.1, we can determine the number of methods that must be implemented on a particular iteration before an expected-positive run for each test case. The number varies depending on how many methods have been implemented on a previous iteration. For example, if test case 1 is tested first, three methods are referred to by the test case, and all three must be implemented before an expected-positive run of that test case. However, if test case 2 is tested next (as earlier), two methods are referred to by the test case, but only one must be implemented in this iteration (because the constructor was already developed in the previous iteration). Table 13.2 lists the methods referenced by each test case and the methods that must be developed as each test case is run, assuming this particular ordering of test runs.

Ideally, it would be nice to minimize the number of methods that are developed at each iteration. The smaller the number of methods that are introduced anew as each test case is run, the easier it will be to pinpoint errors. In this particular example, only two test cases could be completed after the first four methods were developed. Two additional methods had to be written before test case 3 could be completed, at which point test cases 4 through 9 could also be completed. Of course, the number of methods that must be developed at each iteration depends heavily on the order in which the test cases are run. However, other than business value, nothing in this particular process model dictates this order.

A second issue is that test cases should ideally be run as early in the development process as possible. In this example, test cases 8 and 9 could be run immediately after test case 2, immediately after member was written. If we ran these test cases earlier, defects in the methods they refer to (such as add, which is heavily referred to by almost all the remaining test cases) could be exposed in the context of a smaller number of methods. Again, this simpler context could make it easier to pinpoint errors.

Table 13.2. Methods Developed before Each Test Run (Ad Hoc Ordering)
  Test Case Methods Referenced Methods Developed
1. assert(Create().add(1).head()== 1); OrderedList,add,head OrderedList,add,head
2. assert(Create().member(1)== false); OrderedList,member member
3. assert(Create().add(1).tail.equals(Create()); OrderedList,add,tail,equals tail,equals
4.
 OrderedList L = new OrderedList();L = L.add(1);   assert(L.add(2).head()== L.head()); 
OrderedList,add,head  
5.
 OrderedList L = new OrderedList();L = L.add(2);   assert(L.add(1).head() == 1); 
OrderedList,add,head  
6.
 OrderedList L = new OrderedList();L = L.add(2);   assert(L.add(1).tail().equals(L)); 
OrderedList,add,tail,equals  
7.
 OrderedList L = new OrderedList();L = L.add(0);   assert(L.add(1).tail().equals(L.tail.add(1)); 
OrderedList,add,tail,equals  
8. assert(Create().add(1).member(1) == true); OrderedList,add,member  
9. assert(Create().add(1).member(2) == Create().member(2)); OrderedList,add,member  
10.
 assert(Create().add(1).length() ==   Create().length + 1); 
OrderedList,add,length length
11. assert(Create().delete(1).equals(Create())); OrderedList,delete,equals delete
12.
 assert(Create().add(1).delete(1).   equals(Create())); 
OrderedList,add,delete,equals  
13.
 assert(Create().add(1).delete(2).   equals(Create.delete(2).add(1))); 
OrderedList,add,delete,equals  

In the next section, we consider an alternative testing model that specifies the ordering of test case runs and (correspondingly) method development.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net