This XML file is a model of my blog, representing the navigation between tags as a finite state machine.  My Model-Based Testing demo code randomly walks through this model and automatically generates the associated WebDriver test code.

One benefit of Model-Based Testing is demonstrated here, we can simply modify the model to expand the test coverage. Adding more states or more transitions will make those available to the test generation algorithm without adding any new code.

The overall process starts with building the model. In my demonstration, I built the model by inspecting the web-page directly. In a new development, its more likely that we would be working with a specification.  Building the model based on the specification, in parallel with the development team building the software is a powerful method of testing the specifications themselves. I call building the model a second “instantiation of understanding”. The specification team & developers will review the model, and highlight mis-understandings early in the life-cycle.

Once the model is built (and reviewed), we use a test selection method to automatically generate tests. In the demo, I used a random walk through the state machine, but there are other strategies that may be more appropriate.  (cringes while remembering languages & automata CS class)

Next, we extract implementation details from the system under test. In this example, the specific link tags provide the means for the automatic test generation algorithm to create the test input (clicking on a link), and the target page title to be used as the success criteria.

Finally, the demo automatically generates the WebDriver code to implement these tests. In the next post on this series, I’ll describe the code in more detail. For those who want to read ahead, the code is available on gitHub.

A brief word on the model: in the model, each page is represented by a “state”, and the links are a “transition”. The state has an “oracle”, which is the page title. The program uses the oracle to verify correct navigation. The state also has a list of transitions.

Each transition has an input attribute, which is the “class name” for that link, which is how WebDriver will find that link. Each transition also has a next state.  You can find the tag cloud on the side-bar of this blog. Right-click on the link and Inspect Element to see the class name.  (tag-link-3 for automation, for example)