Examples of FsmModel

Interface for FSM models for model-based testing. The classes that implement this interface define Finite State Machine (FSM) models that are used for model-based test generation of unit tests (or of system tests). The FSM model describes the expected behaviour of the underlying system under test (SUT), and can also act as an adaptor (a test harness) which calls the SUT methods and checks their results. Typically, each model will have some internal variables which define the current state of the model. The getState() method must return a public view of those internal state variables, while the reset(boolean) method must reset those internal variables to their initial state. In addition, the model should contain several `action' methods, like this:

 {@code @}Action public void myAction() {...}

which modify the internal state of the FSM. These correspond to the transitions (arcs) of the FSM model. It is also possible to define a guard method on each of these action methods, to say when that action is enabled and when it is disabled.

The FSM model is written as a Java class that has some private state variables and some public methods that act as the transitions of the FSM. It is often written as a wrapper around the system under test (SUT). This FSM class must obey the following rules:

It must implement a void reset(boolean testing) method. This must reinitialise the FSM to its initial state, and if the testing argument is true it must also reset the underlying SUT to its initial state. (It may create a new SUT instance on each call to init, or just once). Advanced Feature: If the SUT test part is expensive, then you may like to save the reset(testing) flag and write all the Action methods so that they do the SUT tests only after a reset(true) call, and do nothing to the SUT after a reset(false) call. However, they must still update the state of the model in both cases.
It must implement a getState() method that returns a representation of the current state of the FSM. The current state of the FSM is usually an abstraction (a simplified view) of the current state of the underlying SUT.
It must have some @Action public void Meth() methods. These define all the transitions of the FSM. Each of these Action methods may change the state of the FSM, and if the testing argument of the most recent init(testing) call was true, then these action methods should test some feature of the underlying SUT and fail if errors are found. If the testing was false, then we are just traversing the FSM to determine its structure, so the SUT tests do not have to be run.
Some actions are not valid in all states, so you can add a guard method to say when that action is enabled. The guard method must have the same name as its action method but with "Guard" added at the end. It must have no parameters and must return a boolean or integer value (the latter are used to define Markov chains for probabilistic testing). The action method will only be called when its guard is true (or greater than 0 in the case of probabilistic guards). So a typical action method with a guard will look like this:
```
 public boolean deleteGuard() { return ...; } {@code @}Action public void delete() { ... perform the SUT test and check results ... fsmstate = ...new state of FSM...; } 
```

@author marku

Examples of nz.ac.waikato.modeljunit.FsmModel