2 Why We Need Model-Based Testing

142 Testing Closed Systems
the model program, which appears in parentheses in the term. The pair of actions is
called a split action. Any action method that has outputs (a return value or C# out or
byref parameters) must be modeled as a split action. You do not have to code both
actions in your model program; the tools automatically create split actions from
every action method with outputs (use the mpv option combineActions- to display
both actions in each pair).
It is necessary to model the two actions separately because the implementation
might not execute the finish action. The start action is controllable; the test harness
can always cause the implementation to execute the method call. But the finish
action is observable; the test harness can only wait for the method return. If the
implementation crashes or hangs, the method will not return and the finish action
will not occur. The test runner indicates that these are failures.
Actions (with no outputs) that are not split actions are called atomic actions.
Actions are not exactly the same as method calls, and (e.g., with split actions) there
is not always a one-to-one relation between method calls and actions. Therefore, we
must distinguish between method names and action symbols, the names of actions.
The default behavior of the library and tools is to automatically derive the action
symbols from method names, but you can also assign your own action symbols in
the action attributes (Appendix A). The entire collection of action symbols used by
a model program is called its action vocabulary or just its vocabulary.
8.3 Test harness
A test harness is code that enables a test runner to execute an implementation. You
must write a test harness for each implementation. Figures 8.4 and 8.5 show the
test harness that connects the client/server implentation to the ct tool. The implementation
appears in Chapter 2, Figures 2.3–2.5.
You can write the harness to accommodate differences between the model and
the implementation. The harness in Figures 8.4 and 8.5 drives an implementation
where sockets are objects, but in the model they are static variables. Although the
library and tools use .NET, you can write a harness for an implementation that does
not use .NET.
Write the test harness in the same namespace as the implementation. The test
harness implements the modeling library’s IStepper interface, so we often call a
test harness a stepper; it “steps” the implementation through the actions of each test
case. To implement the IStepper interface you must write two methods, Reset and
DoAction. The stepper must also provide a factory method that returns the stepper
object.
The Reset method executes after each test case to reset the implementation to its
initial state.
more free ebooks download links at:
http://www.ebook-x.com