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 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.
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:
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.
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.
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 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 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 failed.
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:
| Remember that you could model it completely differently; modeling represents a perspective. |
Let's pick the NewOwner model as an example.
v_NewOwner represents, accordingly to what we've defined for our model, being on the "New Owner" page.
If we fill correct data (i.e. using the edge "e_CorrectData"), we'll be redirected to a page showing the owner information.
Otherwise, if we fill incorrect data (i.e. using the edge "e_IncorrectData") an error will be shown and the user keeps on the "New Owner" page.
The Java class that implements the edges and vertices of this model is defined in the class 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.
package com.company.modelimplementations;
import com.company.NewOwner;
import com.github.javafaker.Faker;
import org.graphwalker.core.machine.ExecutionContext;
import org.graphwalker.java.annotation.GraphWalker;
import org.openqa.selenium.By;
import static com.codeborne.selenide.Condition.text;
import static com.codeborne.selenide.Condition.visible;
import static com.codeborne.selenide.Selenide.$;
import static com.codeborne.selenide.Selenide.$x;
/**
* Implements the model (and interface) NewOwnerSharedState
* The default path generator is Random Path.
* Stop condition is 100% coverage of all edges.
*/
@GraphWalker(value = "random(edge_coverage(100))")
public class NewOwnerTest extends ExecutionContext implements NewOwner {
@Override
public void v_OwnerInformation() {
$(By.tagName("h2")).shouldHave(text("Owner Information"));
$x("/html/body/div/table[last()]/tbody/tr/td[2]/img").shouldBe(visible);
}
@Override
public void e_CorrectData() {
fillOwnerData();
$(By.id("telephone")).sendKeys(String.valueOf(new Faker().number().digits(10)));
$("button[type=\"submit\"]").click();
}
@Override
public void e_IncorrectData() {
fillOwnerData();
$(By.id("telephone")).sendKeys(String.valueOf(new Faker().number().digits(20)));
$("button[type=\"submit\"]").click();
}
@Override
public void v_IncorrectData() {
$(By.cssSelector("div.control-group.error > div.controls > span.help-inline"))
.shouldHave(text("numeric value out of bounds (<10 digits>.<0 digits> expected)"));
}
@Override
public void v_NewOwner() {
$(By.tagName("h2")).shouldHave(text("New Owner"));
$x("/html/body/table/tbody/tr/td[2]/img").shouldBe(visible);
}
private void fillOwnerData() {
$(By.id("firstName")).clear();
$(By.id("firstName")).sendKeys(new Faker().name().firstName());
$(By.id("lastName")).clear();
$(By.id("lastName")).sendKeys(new Faker().name().lastName());
$(By.id("address")).clear();
$(By.id("address")).sendKeys(new Faker().address().fullAddress());
$(By.id("city")).clear();
$(By.id("city")).sendKeys(new Faker().address().city());
$(By.id("telephone")).clear();
}
} |
To run the tests we can use Maven.
mvn graphwalker:test |
This will produce a single JUnit XML report, with one testcase element per each model.