2 Why We Need Model-Based Testing

128 Structuring Model Programs with Features and Composition
Now we introduce another style, the FSM model program. Figure 7.12 shows
M1 coded in this style. It also uses C#, but instead of coding state variables and
action methods, we code the FSM as an array of strings where each string describes
one transistion, in the format "t(current state, action, next state)". The
current state in the first transition is the initial state. In the factory method, the array
of strings is passed to the FSM.Create method, which returns an instance of the FSM
class. Another method in this class can be used to identify the accepting states, if
any. The FSM instance is passed to the constructor for the FsmModelProgram class,
which is also derived from ModelProgram. An FSM model program is compiled and
displayed in exactly the same way as a library model program.
Now we introduce a third style, the FSM text file, which is the most compact
(Figure 7.13). This style dispenses with C# and assemblies altogether and just puts
the FSM in a text file, in a parenthesized format. The first element inside the outer
parentheses is the initial state. The second element is a sequence of accepting states
(which is left empty here, which indicates there are no accepting states). It is not
necessary to compile an FSM file. To display the FSM in the file, invoke mpv with
the /fsm option and name the file:
mpv /fsm:M1.txt
In practice, we rarely write an FSM model program, we just write an FSM text
file instead. When you invoke a tool with the /fsm option, it reads the FSM from
the file and constructs a FsmModelProgram instance in much same way as shown in
Figure 7.12. The tools do require you to write a factory method for library model
programs (rather than just invoking the constructor automatically) because this is
where you identify the features you want to include.
The tools do not depend on the source form of model programs. They access every
model program in a uniform way through an instance of the ModelProgram class,
which always provides certain properties and methods, including InitialState,
GetActions, GetTargetState, and so on. (Chapter 6, Section 6.2.4). As a result,
every style of model program can be composed, explored, viewed, and used for
testing in the same way. From the tools’ point of view, the differences between
model program styles are hidden by derived types such as LibraryModelProgram and
FsmModelProgram. It is possible to support model programs written in other styles
and languages by coding additional types derived from ModelProgram. For example,
you could support model programs that are expressed as diagrams rather than text.
7.3.3 Scenario model programs
Now that we understand composition and know how to write scenario model programs
easily, we are ready to use composition for scenario control.
more free ebooks download links at:
http://www.ebook-x.com