Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 edges can be "walked" and performs JavaScript based actions to set internal context variables . It stops "walking" if stop condition(s) are met.

...

In GraphWalker, the testing is performed continuously by walking a path (conditioned by as a result of its generator) and until certain condition(s) is(are) met.

This is a bit different from traditional, sequential test scripts where each one has a set of well-defined actions and expected results.

The straighforward approach is to We can say that GraphWalker produces dynamic test cases, where each one correponds 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.

Requirements

What about "requirements"?

...

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

In MBT, especially in the case of State Transition Model-Based Testing, we start from a given vertex . But but then the path, that describes the sequence of edges and vertices visited, can be quite different each time the tool generates it. Besides, the stop condition is not composed by one or more well-known and fixed expectations; it's based on some more graph/model related criteria.

When we "execute the model", it will keep transversing/walking the path and performing checks in the vertices. If those checks are successful until the stop condition(s) is achived, we can say that it was successful; otherwise, the model failedthe 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 model+codewiki page describing it) which targets the well-known PetClinic sample site.

Image Modified


Requirements

  • Java 8 
  • PetClinic sample application (requires Java 8 as it is)
    • git clone https://github.com/SpringSource/spring-petclinic.git
      cd spring-petclinic
      git reset --hard 482eeb1c217789b5d772f5c15c3ab7aa89caf279
      mvn tomcat7:run
  • GraphWalker
  • GraphWalker Studio


How can we test the PetClining PetClinic 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.

...

Models can be built using GraphWalker Studio. We can use it to load previously saved model(s) like the ones in graphwalker-example/java-petclinic/src/main/resources/com/company/PetClinic.json. In this case, the JSON file contains several models; we could also have one JSON file per model.

The following picture shows the overall PetClinic model, that interacts with other models.

GraphWalker Studio allow us to run the model in offline, i.e. without executing the underlying test automation code, so we can validate it.

...

The Java class that implements the edges and vertices of this model is defined in the class NewOwnerTestclass NewOwnerTest. Actions performed in the edges are quite simple. Assertions are also simple as they're only focused on the state/vertex they are at.

...

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 The @GraphWalker annotation is used to specify the path generator and stop conditions. This is used for online path generation during test execution. 

...

Info
titlePlease note

Tests using the model can also be created and executed programatically similar to other tests, using JUnit or other testing framework. More info here and here.

The flow is would be something like:

  1. create a TestBuilder object
  2. create a Context object
  3. add the Context to the TestBuilder
  4. execute it, using .execute()
  5. optionaly, look at the Result object returned to see if it has errors, using .hasErrors()


Code Block
languagejava
titleexample of some Tests implementing using JUnit
collapsetrue
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();
    }
}


In this case, we could execute the tests using Maven. We would then use the JUnit XML report produced by JUnit itself.

mvn test




To run the tests online with GraphWalker we can use Maven, since there is  a specific plugin for assisting on 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 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 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" 
    • Image Modified
  • 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 coverage directly on the respective issue, or even on a Agile board
    • Image RemovedImage Added 
    •   Image RemovedImage Added  Image RemovedImage Added

References