2 Why We Need Model-Based Testing

Systems with Finite Models 83
Features
We will model all of the features of the implementation Controller class (Chapter 3,
Section 3.1).
We must also model the controller’s environment: the timer, sensor, and supervisor
(Chapter 3, Figure 3.1). This is necessary in order to model events realistically. In
our sandbox implementation, simulated events were generated by the user (through
the Simulator class, Figures 3.5 and 3.6) or by the test fixture (Figure 3.7). In the
model, we cannot use a .NET timer as we did in the simulator, because the time-out
events must be scheduled by the tools.
Actions
There is an action in the model program for every event handler in the implementation’s
Controller class: Reset, Poll, and so on. The enabling conditions
for these actions are the same as the guards in the implementation: ResetEnabled,
PollEnabled, and so on. There is no action in the model corresponding to the implementation’s
DispatchHandler method; its control structure is implicit in the enabling
conditions.
There is also an action for each kind of event that the reactive program handles. In
the implementation, there is a single method ReceiveEvent with a cevent parameter
that indicates what kind of event occured. Our several event actions correspond
to different invocations of ReceiveEvent with different values for cevent. In the
model, it turns out to be simpler to define a different action for each type of event,
because each has a different enabling condition and makes different updates to the
model state. In fact, there are more of these action methods than event types. For the
Timeout event, we have the actions Timeout, TimeoutMsgLost, and TimeoutMsgLate.
The additional code in our several event actions (compared to ReceiveEvent) is
necessary because the model program must model the environment that generates
events, in addition to the controller.
The model program alternates between executing an event action and a handler
action. We have to define a do-nothing handler NoHandler to model what happens
when no handler is enabled in the implementation.
Traces
We write some sample traces to show how behaviors discussed in Chapter 3 are
expressed in the action vocabulary we chose. The run coded in the test method
named Typical (section 3.3) is expressed by this trace:
Timeout();
Reset();
Message("99.9");
CheckMessage();
more free ebooks download links at:
http://www.ebook-x.com