You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Overview


GraphWalker is a tool that addresses State Transitioning 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 some key concepts, using the information provided by GraphWalker's documentation that explains them clearly:

  • edge: An edge represents an action, a transitionAn action could be an API call, a button click, a timeout, etc. Anything that moves your System Under Test into a new state that you want to verify. But remember, there is no verification going on in the edge. That happens only in the vertex.
  • vertex:  A vertex represents verification, an assertion. A verification is where you would have assertions in your code. It is here that you verify that an API call returns the correct values, that a button click actually did close a dialog, or that when the timeout should have occurred, the System Under Test triggered the expected event.
  • modelA model is a graph, which is a set of vertices and edges.


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.


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").

Each model has an internal state with some variables - its context. Besides, and since GraphWalker can transverse multiple models, there is also a global context.


We can also add actions and guards to the model, which can affect how the model is walked and how it behaves:

  • action: a way of setting variables in the model or global context; actions are mplemented 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 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.

To build the model, we can use a visual tool and (GraphWalker Studio) and export it to a JSON file.

Mapping concepts to Xray

Besides other entities, in Xray we have Test issues and "requirements" (i.e. issues that can be covered with Tests).

In GraphWalker, the testing is performed continuously by walking a path (conditioned by 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 consider each model a Test. Remember that a model in itself is a test idea, something that you want to validate; therefore, this seems a good fit.

What about "requirements"? Well, even though GraphWalker allows you to assign one or more requirement identifiers to each vertex, it may not be the best 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.

Example

In this tutorial, we'll use GraphWalker e-commerce PetClinic example which uses the well-known PetClinic sample site.


How can we test it using MBT?

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 this example, our models are:

  • PetClinic: main model of the PetClinic store, that relates several models provided by different sections in the site
  • FindOwners: model around the feature of finding owners
  • Veterinarians:  model around the feature of listing veterinarians
  • OwnerInformation: model around the ability of showing information/details of a owner
  • NewOwner: model around the feature of creating a new owner


Please note

Remember that you could model it completely differently; modeling represents a perspective.



References

  • No labels