...

GraphWalker is a tool that addresses State Transition Model-Based Testing; in other words, it allows you to perform modeling around states and transitions between those states using directed graphs. 

Starting by clarifing Here is some clarification around some key concepts , using the information provided by GraphWalker's documentation that explains them clearly:

...

From a model, GraphWalker will generate a path through it. A model has a start element, and a generator which rules how the path is generated, and associated stop condition which tells GraphWalker when to stop generating the path.

Generators and stop condtions conditions are essential in GraphWalker (more info here and here), as they influence how the model will be transversed "walked" and until when.

Multiple models can interact with one another (i.e. jump from one to other and vice-versa), using shared states (i.e. vertices that have a "shared name").

...

• action: a way of setting variables in the model or global context; actions are mplemented implemented using JavaScript
• guard: a way of blocking/guard edges from being walked/executed, usually considering variables stored in the model or global context; guards are implemented using JavaScript.

...

In sum, we model (i.e. build a model) a certain aspect related to our system using directed graphs; the model represents a test idea that describes expected behaviors. Checks are implemented in the vertices (i.e. states) and actions are performed in the edges. GraphWalker will then "walk" the model (i.e. perform a set of "steps"/edges) using a generated path. While doing so, it looks at JavaScript guards to check is if edges can be "walked" and performs JavaScript based actions to set internal context variables . It stops "walking" if stop condition(s) are met.

...

We can say that GraphWalker produces dynamic test cases, where each one correponds corresponds to the full path that was generated. Since the number of possible paths can be quite high, we can follow a more straightforward approach: consider each model a Test, no matter exactly what path is executed. Remember that a model in itself is a high-level test idea, something that you want to validate; therefore, this seems a good fit as long as we have the means to later on debug it.

...

Well, even though GraphWalker allows you to assign one or more requirement identifiers to each vertex, it may not be the best most suitable approach linking our model (or parts of it) to requirements. Therefore, and since we consider the model as a Test, we can eventually link each model to a "requirement" later on in Jira.

...

In sequential scripted automated tests/checkeschecks, we look at the expectactionexpectation(s) using assert(s) statement(s), after we perform a set of well-known and predefined actions. Therefore, we can clearly say that the test scenario exercised by that test either passed or failed.

...

When we "execute the model", it will keep transversing/walking the path walk the path (i.e. go over from vertex to vertex through a given edge) and performing checks in the vertices. If those checks are successful until the stop condition(s) is achivedachieved, we can say that it was successful; otherwise, the model is not a good representation of the system as it is and we can say that it "failed.".

Example

In this tutorial, we'll use an example provided by the GraphWalker community (please check GraphWalker wiki page describing it) which targets the well-known PetClinic sample site.

...

How can we test the PetClinic website using MBT technique?

Well, one approach could be to model the interactions between different pages. Ultimately they represent certain features that the site provides and that are connected with one another.

...

In the previous example, we can see that the class NewOwnerTest extends ExecutionContext; this ties the model with the path generator and provides a context for tracking the internal state and history of the model while it is transversed.

The @GraphWalker annotation is used to specify the path generator and stop conditions. This is used for online path generation during test execution. 

...

public class SimpleTest extends ExecutionContext implements Login {
    public final static Path MODEL_PATH = Paths.get("org/myorg/testautomation/Login.json");
...
    @Test
    public void runSmokeTest() {
        new TestBuilder()
                .addContext(new SimpleTest().setNextElement(new Edge().setName("e_Init").build()),
                        MODEL_PATH,
                        new AStarPath(new ReachedVertex("v_Browse")))
                .execute();
    }

    @Test
    public void runFunctionalTest1() {
        new TestBuilder()
                .addContext(new SimpleTest().setNextElement(new Edge().setName("e_Init").build()),
                        MODEL_PATH,
                        new RandomPath(new EdgeCoverage(100)))
                .execute();
    }

    @Test
    public void runFunctionalTest2() {
        TestBuilder builder = new TestBuilder()
                .addContext(new SimpleTest().setNextElement(new Edge().setName("e_Init").build()),
                        MODEL_PATH,
                        new RandomPath(new EdgeCoverage(100)));
        Result result = builder.execute(true);
        Assert.assertFalse(result.hasErrors());
    }

    @Test
    public void runStabilityTest() {
        new TestBuilder()
                .addContext(new SimpleTest().setNextElement(new Edge().setName("e_Init").build()),
                        MODEL_PATH,
                        new RandomPath(new TimeDuration(30, TimeUnit.SECONDS)))
                .execute();
    }
}

...

To run the tests online with GraphWalker we can use Maven, since there is  is a specific plugin for assisting on with this. This will produce a single JUnit XML report stored in the target/graphwalker-reports/ directory.

...

The Execution Details page also shows information about the Test Suite, which will be just "GraphWalker.".

Tips

• Use MBT not to replace existing test scripts but in cases where yoou you need to provide greater coverage
• Discuss the model(s) with the team and the ones that can be most useful for your use case
• You can control the seed of the random generator used by GraphWalker, so you can easily reproduce bugs (i.e. by reproducing the generated path)
• You can use GraphWalker Player to see the graph being transversed in walked in real-time. You can use a sample HTML file that contains the code to connect to a WebSocket server that you need to instantiate in the runner side (example) .
  • Example:
    
    • open the file index.html in your browser, using an URL such as "file:///Users/you/index.html?wsURI=localhost:8887?wsURI=localhost:8887"
    • execute GraphWalker, using the custom runner
      • mvn exec:java -Dexec.mainClass="com.company.runners.WebSocketApplication" 
  • 
• Multiple runs of your tests can be grouped and consolidate in a Test Plan, so you can have an updated overview of their current state
• After importing the results, you can link the corresponding Test issues with an existing requirement or user story and thus truck track coverage directly on the respective issue, or even on a an Agile board
  •  
  •     

References

...