In
this example, we had to execute several methods in the correct sequence to set up
the client/server connection before we could execute the defective code. Even then,
executing the defective code did not cause a failure immediately. The defective code
affected storage (or state), so the failure did not occur until later. Such defects cannot
be exposed by typical unit tests (as in Section 2.6), where we only execute a short
sequence of method calls (perhaps just one) and check a single result.
It is possible to code more realistic runs in unit tests, as we attempted in Section
2.8, but this requires a great deal of effort. Unit test tools only automate test
execution and logging test results; they still require the tester to code every run and
each assertion. Some unit testing guides recommend writing as much or more test
code as implementation code.5 Our barely realistic unit test (Figure 2.10) is almost
as long as the main methods in our applications (Figures 2.7 and 2.8). It is still too
short; it did not detect the defect.
We need more automation to generate and check realistic runs for testing. Simply
calling methods at random would not work; we need meaningful sequences of
method calls.
2.12 Model-based testing reveals the defect
Our methods automate test generation and checking, in addition to test execution
and logging. The tester must describe the ordering constraints on methods and the
intended results of methods by writing a model program.
Pages:
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65