2 Why We Need Model-Based Testing

74 Model Programs
ServerSend(212.0);
ClientReceive(); // should return 212.0
ClientClose();
ServerCloseConnection();
ServerClose();
Here server.Socket in the implementation is modeled by ServerSocket in the
model program, and so on. The arguments of Bind, Connect, and the client’s Send
in the implementation are not needed in the model program. We use a comment to
indicate the expected return value of ClientReceive in this trace. We explain how
return values are handled in the NModel framework in Chapter 8, Section 8.2.
State variables
In the implementation, there are classes for the client and server, and particular
clients and servers are instances. Any program with instances is potentially “infinite,”
because it can create an unlimited number of them. We must make our model program
finite. In our tests, we will only have one client and one server, so instances are not
needed. In our model program, the state variables are the static variables needed to
model just one client and one server. This is an example of data abstraction. A model
program where all variables are static can model an implementation with instances
and can be connected in a test harness with that implementation (Chapter 8).
Recall that state variables can store control state that determines the sequence
of actions. In this example, there are two kinds of constraints on that sequence.
Sockets must be created, connected, and closed according to the protocol shown
in Chapter 2, Figure 2.2. And, the send and receive actions must alternate, always
beginning with a send action. Therefore we have three state variables for the control
state. Two keep track of each partner’s step in the protocol: clientSocket and
serverSocket. The third synchronizes send and receive actions: phase. These three
variables do not correspond closely to any variables in the implementation. In the
implementation, the ordering of method calls is coded in the applications that call
them.
Recall that state variables can hold data state that stores the arguments and return
values of actions. In this example, the data state is the most recently acquired
temperature. We store the data state in a single state variable. It turns out to be most
convenient to use the client’s receive buffer clientBuffer.
The temperature is a number. All numeric types are “infinite”: not mathematically
infinite, but too large to store every value. Any program that uses numbers is
potentially “infinite” (i.e., it has an “infinite” state space). To finitize our model, we
must limit it to a finite collection of temperatures; the smaller, the better. We decide
to use just two. We suspect that there might be defects in the implementation that
more free ebooks download links at:
http://www.ebook-x.com