2 Why We Need Model-Based Testing

72 Model Programs
that the sequence of actions coded in this method is not allowed by the model
program. This means that the implementation is not able to execute this sequence.
Simulation is the most limited and labor-intensive model-based analysis technique
because it only considers one run at a time. To perform more thorough
analyses – to detect the design errors discussed in Chapter 3, for example – we need
to consider many different runs. For this, we use a more powerful analysis technique
called exploration, which we will discuss in Chapter 6.
We recommend that you simulate and explore your model program as you develop
it, so you can check frequently that it behaves as you intend. There is no need to
finish the model program first; you can begin analyzing as soon as you have coded
a few actions. The mpv tool makes it easy, as we shall see in Chapter 6. But first, we
present model programs for the two implementations in Part I.
5.6 Case study: client/server
In this section we model the client/server system discussed in Chapter 2. In this
example, we have the implementation available to help us with preliminary analysis
and coding.
This example shows how a single model program can represent a distributed
system with programs running on two computers connected by a network.
5.6.1 Preliminary analysis
The first activity in writing a model program is always a preliminary analysis.
Recall that in preliminary analysis, we decide on a purpose for the model, select the
features to include, and choose a level of abstraction by identifying the actions and
state variables to represent in the model.
Purpose
The purpose of this model is to automatically generate and check test runs that can
detect defects like the one described in Chapter 2, Sections 2.9 and 2.10.
We will execute these tests in a configuration similar to the one where we executed
the unit test described in Chapter 2, Section 2.8: asandbox where both the client
and server are controlled by the test runner, and both execute in a single thread,
interleaving their method calls in an order that conforms to their protocol (Chapter 2,
Figure 2.2).
We want a contract model that can generate all the runs that the client and server
can successfully execute in the sandbox. By a “run,” we mean a session where both
client and server create sockets, possibly exchange some messages, and then close
their sockets. By “successfully execute,” we mean every method call returns, and no
more free ebooks download links at:
http://www.ebook-x.com