2 Why We Need Model-Based Testing

120 Structuring Model Programs with Features and Composition
0
ServerSocket()
1
ServerClose()
ServerBind()
3
2
ServerListen()
ServerClose() 4
ServerClose()
Figure 7.4. Client/server: server feature included, client feature not included.
all of its action methods are true (in all the included features and other classes).
During exploration, the combined action is executed repeatedly in each state, with
each combination of parameter values that is enabled in all of the features. When
the combined action executes, all of the action methods for that action execute, as if
in parallel (actually, in some order that cannot be predicted). This only makes sense
if the next state after executing all the action methods is the same for any order of
execution. This is assured if none of the action methods assigns state variables that
are used by other action methods in the same action.
Here we show how to combine features to control parameter generation, an
aspect of scenario control. Recall that each parameter of each action method must
be provided with a domain, a set of argument values for that parameter. In each
state, exploration executes each action method repeatedly, using as many different
values as it can from the domains of all its parameters, so larger domains result in
more transitions and more runs. Therefore, selecting domains can limit or select
runs. In our examples in Chapter 5, each domain is coded directly into the contract
model program. In the client/server example, one particular domain Temperatures
is always used for the datum parameter of the ServerSend action method:
[Action]
static void ServerSend([Domain("Temperatures")] double datum)
...
static Set Temperatures()
...
more free ebooks download links at:
http://www.ebook-x.com