2 Why We Need Model-Based Testing

214 Testing Systems with Complex State
Probes typically increase the possibility of finding errors earlier. We can see how
ct discovers the bug in the faulty bag implementation much sooner than before,
by using CreateModelWithProbe composed with ProbeScenario and AddDeleteScenario
TestResult(1, Verdict("Failure"),
"Inconsistent views of state: model:Set() iut:Set(\"b\")",
Trace(
Add("b"),
CheckView(Set("b")),
Delete("b"),
CheckView(Set())
)
)
12.5.2 Test execution and termination
The two primary options of ct that directly control the size of a generated test suite
are runs and steps. The value of runs is the desired number of test runs. Each test
run starts from the initial state of the model program. Both the IUT and the strategy
are reset between test runs. Recall that resetting the strategy resets the underlying
model program. This is an outline of the top-level loop:
int k = 0;
while (k < runs)
{
if (!TestResultNotifier(RunTest(k))) return;
strategy.Reset();
stepper.Reset();
k += 1;
}
The test result notifier is a delegate that can be set in the conformance tester. This
delegate controls when the conformance tester should terminate. In ct this delegate
is set to a function that outputs the test result and returns false, if the test run failed
and the continueOnFailure option of ct is turned off, and returns true otherwise.
Each test result is written either to the console or to a log file if one is provided by
the logfile option of ct.
Test execution algorithm. An outline of the algorithm that executes a single
test run is shown in Figure 12.7. Each individual test run starts from the initial
state and attempts to produce a run of at least as many actions as specified by
more free ebooks download links at:
http://www.ebook-x.com