2 Why We Need Model-Based Testing

Systems with Finite Models 95
Table 6.1. Newsreader scenario FSM: state transition table
Current state Action (invocation) Next state
Topics, WithText, ShowTitles() Topics, TitlesOnly,
ByMostRecent ByMostRecent
Topics, TitlesOnly, SortByFirst() Topics, TitlesOnly,
ByMostRecent ByFirst
Topics, TitlesOnly, SortByMostRecent() Topics, TitlesOnly,
ByFirst ByMostRecent
Topics, TitlesOnly, ShowText() Topics, WithText,
ByMostRecent ByMostRecent
To describe a run of a model program, we only need to show the actions (the
action method calls). More thorough analyses must use the states as well. When we
consider states and actions together, we find that an action often causes a change of
state: a state transition. FSMs are built up from state transitions, not just actions.
To completely describe each state transition, we must identify the current state before
the transition, the next state after the transition (also called the target state), and
the action. To completely describe each action, we must show the entire invocation
(the action name and all of its arguments) and the return value (if there is one).
An FSM is simply a finite collection of state transitions described in this way,
along with an identification of the initial state where every run begins, and optional
accepting states where runs are allowed to end (if no accepting states are identified,
runs may end in any state). A run is a sequence of state transitions, so any run can
define an FSM. But a run is an ordered collection, while an FSM is unordered. It
is not necessary to order the FSM because each transition identifies its current and
next states.
An FSM can be represented by a state transition table or a state transition diagram.
Table 6.1 shows the state transition table that represents the FSM for the successful
simulation run of Chapter 5, Section 5.5:
ShowTitles(); SortByFirst(); SortByMostRecent(); ShowText();
We simply enter a row in the table for each transition in the run, filling in the states
and the method calls from the output of the run. An FSM is an unordered collection,
so we can put the rows in any order we like. In our tables, we always put the
transitions that begin in the initial state in a separate section at the top of the table,
separated by a double line. After that, we put all transitions that begin in the same
state together in the table. These are just conventions that make the table easy to
read; any other order would express the same FSM. Often, rows in our tables appear
in a different order than that in which the transitions occur in our example runs.
more free ebooks download links at:
http://www.ebook-x.com