2 Why We Need Model-Based Testing

Systems with Finite Models 141
TestSuite(
TestCase(
ServerSocket(),
ServerBind(),
ServerListen(),
ClientSocket(),
ClientConnect(),
ServerAccept(),
ServerSend(double("100")),
ClientReceive_Start(),
ClientReceive_Finish(double("100")),
ServerSend(double("99.9")),
ClientReceive_Start(),
ClientReceive_Finish(double("99.9")),
ClientSend(),
ServerReceive(),
ClientClose(),
ServerCloseConnection(),
ServerClose()
)
)
Figure 8.3. Client/server: test suite file contents, showing a trace with terms.
The otg tool saves test suites in text files. Figure 8.3 shows the contents of
ScenarioTest.txt, which describes the test suite with one test case whose FSM
is displayed in Figure 8.2. Each test case in a test suite file is a trace, text that
represents a program run. A trace is not expressed in C# code, although it resembles
code (compare the trace in Figure 8.3 to the unit test in Chapter 2, Figure 2.10,
and also to the trace we wrote in Chapter 5, Section 5.6.1). A trace is a sequence
of actions. Each action is expressed as a term, a data structure that the tools use to
represent actions. The syntax of terms is easy to understand, but differs from the
syntax of C# method calls. The tools use terms because they are easier to work with
than program text. You must work with terms in your test harness code.
Actions are not exactly the same as method calls. Most of the actions in Figure 8.3
correspond to a method call, but not all. Each client Receive method call corresponds
to two actions, for example:
ClientReceive_Start(),
ClientReceive_Finish(double("100")),
The first action, called the start action, is the method call. The second action, the
finish action, is the method return including the expected return value computed by
more free ebooks download links at:
http://www.ebook-x.com