ModelJUnit tutorial¶

Domain definition¶

First we create a list of input to test the features of our SUT.

State space¶

Some input are only available on certain pages. For instance, you can only login from the login page, or you can only add files on the lab page, etc. This gives us the operational mode Page = { Login, Home, Lab }

Adding and removing files (as well as submitting) are only possible if the submission is not yet submitted, so we have the operational mode LabStatus = { Open, Submitted }

Finally, to remove a file there need to be at least one file in the system, so we can add an additional mode NbFiles = { n \in N, n >= 0}. (Note that, unlike the operational modes in the paper, this one has an infinite number of possible values).

So every state in my model is a combination of a Page value, a LabStatus value and a NbFiles value. For instance, Login, Open, 2 or Lab, Submitted, 1.

Transition table¶

The transition table describes, for each possible state and each input, what is the resulting state. Invalid combination of State+input are omitted (e.g. Home, Open, 0 and login).

Model diagram¶

I need to choose which of my operational modes are best represented in the visible states (the bubbles) and which should be internal variables.

One possible way to do that is to represent finite values (i.e. Page and LabStatus) in the visible states and infinite mode (i.e. NbFiles) as internal variables, giving the following diagram with the internal variable $f representing the number of uploaded files, initialized to 0:

But we can see a lot of redundancy here and maybe we can get a simpler diagram by treating LabStatus as an internal variable $s initialized to Open (in addition to the $f variable as before). This creates a smaller diagram but note that we then need more guards:

We could push this to the extreme and have only internal variable and a single visible state, but this is silly. Don’t do it!

The model in code¶

First we implement the FsmModel interface to define our eFSM in ModelJUnit:

For every input in our model, we are going to write a ModelJUnit Action:

@Action
public void myInput() {
  // Here we should update the current state...
}

and a guard that’ll tell ModelJUnit when this action is available. The guard should be a method with the name <input>Guard and return a boolean, e.g.:

public boolean myInputGuard() {
  return /* true if the current state allows myInput, false otherwise */
}

The Adapter¶

Next we implemented the adapter that allows our model to communicate with and take control of our SUT.

For each one of the @Action method in the model, we added a similarly named method in the adapter class:

class MyAdapter [
  // ...
  public void myInput() {
    // Here we execute myInput on the SUT
  }
  // ...

and, in the model, we make sure that each @Action calls the right adapter method:

class MyModel implements FsmModel {
 // ...
 @Action
 public void myInput() {
   // ...
   adapter.myInput();
 }

Implementing reset¶

One of the methods that you need to implement as part of the FsmModel interface is reset. In this method, your model is supposed to reset itself as well as reset the SUT to a known state.

Implementing getState¶

The second method that the FsmModel interface requires you to implement is getState. This method should return an object, often a string, which uniquely identify the current state. It should correspond to the Visible States of your model (the states in the bubbles).

Generating tests¶

Once you have implemented your model, you can use it to generate tests. In the tutorial example, tests were generated in the main method:

public static void main(String[] argv) {
    MyModel model = new MyModel();
    //Tester tester = new LookaheadTester(model);
    RandomTester tester = new RandomTester(model);
    //Tester tester = new AllRoundTester(model);
    //Tester tester = new GreedyTester(model);
    tester.buildGraph();
    tester.addListener(new VerboseListener());
    tester.addListener(new StopOnFailureListener());
    tester.addCoverageMetric(new TransitionCoverage());
    tester.addCoverageMetric(new StateCoverage());
    tester.addCoverageMetric(new ActionCoverage());
    tester.generate(20);
    tester.printCoverage();
}

First, we need to instantiate your model:

MyModel model = new MyModel();

Then, we choose the test strategy. ModelJUnit offers four different strategies: AllRoundTester, GreedyTester, LookaheadTester and RandomTester:

RandomTester tester = new RandomTester(model);

Next we tell the tester to try and build the graph from the model implementation. This will basically generate a lot of tests until ModelJUnit thinks it has seen all the states. It’ll be used later to compute the coverage metrics. (Hint: if you want the graph building to go faster, you can write your model so that it is possible to connect the adapter after you have run buildGraph):

tester.buildGraph();

Then, we tell ModelJUnit to collect some information about the test run:

tester.addListener(new VerboseListener());
tester.addCoverageMetric(new TransitionCoverage());
tester.addCoverageMetric(new StateCoverage());
tester.addCoverageMetric(new ActionCoverage());

tester.addCoverageMetric(new StateCoverage() {
    @Override
    public String getName() {
        return "Total state coverage";
    }
});

This tells ModelJUnit to stop the test on the first failure:

tester.addListener(new StopOnFailureListener());

Final, we generate a test sequence with a given length and print the collected metrics:

tester.generate(20);
tester.printCoverage();