2 Why We Need Model-Based Testing

30 Why We Need Model-Based Testing
different methods from several classes, and observe the effects of each method. 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. Our technology can then
use the model program to automatically generate and check realistic runs of any
desired length. Moreover, our methods can handle nondeterminism, so we can run
more realistic tests where we only control one end of the client/server pair.
We develop a model program for analyzing and testing this system in Chapter 5.
We automatically generate tests from this model program in Chapter 8. Hereisa
test run that reveals the defect:
TestResult(0, Verdict("Failure"),
"Action ’ClientReceive_Finish(double(\"99\"))’ not enabled in the model",
Unexpected return value of finish action, expected:
ClientReceive_Finish(double "99.9"))
Trace(
Test(0),
ServerSocket(),
ServerBind(),
ServerListen(),
5 For example, see Rainsberger (2005, p. 79).
more free ebooks download links at:
http://www.ebook-x.com