Hi everyone, In case you want to try and learn more about Model-Based Testing using Python, I’ve ported an example for AltWalker and the PetClinic application.
This code is highly based on a previous example for GraphWalker and Java but I’ve made some subtle changes to also make it a bit more modular/cleaner.
Full source-code and some documentation here.
Feel free to fork, improve, submit PRs 
Enjoy.
Can you tell us a little bit about why on earth anyone would want to use directed graph in testing a product? Surely it assumes you can generate the graph from static or runtime analysis of a product? or is the tool intended for certain kinds of application only?
Well, for several reasons.
I have detailed a few of them in this blog post.
MBT is a great way to increase cover coverage and go through different paths in your application, no matter if it’s UI or not based; these would be otherwise impossible to tackle.
Modeling is an abstraction, that also is easy to visualize and to the team discuss around it. More, you can create different models that cover a certain feature (or even the app) from different angles and then exercises all possible interactions and sequences in there.
If you want to know more, I have some references to some open-source tools that also go into some details.
Was asking, because prior experience of model based system required upwards of 5 dedicated people to maintain the graph, leading to a bit of tension. I really liked the knowledge captured in a graph form, as it helped me know where to focus when designing an E2E test.
Most excellent blog explainer Sergio. Too often in these times of agile engineering, tools like MBT get ignored because they entail investment in new languages and tools. Anything that can create inertia gets discarded far too easily. Over time I got the impression it was really only good for regression testing. Turning the model into runnable test cases was costly because we wrote all or own frameworks and tools back then. My experience of MBT is that the detractors of it win in the end because it needs a champion who can continuously evolve the processes around the system every time a new challenge arises.
Although it’s a great place to learn about product interactions, for me it failed to draw in environment and hardware integrations/inter-op, like different browser versions or networks, that provided a much greater source of valuable defects discovered to us. Would love to see a “lite” version of this tooling to support ad-hoc or exploratory test sessions.
In my yet brief experience, this is very useful when handling legacy systems. But I’m aware of people using for in-sprint automation and exploring while software is being built because we model our understanding and then it can easily be validated, even without automation code implemented.
Writing the underlying code can be a bit or more complex; until now I actually find it easier because we just focus on the transitions and the states in isolation and the code for them is usually more restricted.
In another exercise I’ve done, this technique was very useful for validating an algorithm; there are some challenges though (I’ll have to write it later on).
Even if you never write tests for the model, the model is really good way of talking though corner cases and designs. Yes, very much suited to legacy systems as a tool, but a lightweight or throw-away model is helpful when analysing.
I really hope they start to teach this as a tool or approach to design at University level though.
Really cool stuff, thank you for sharing. I was working on GraphWalker back in the days nice to see it being done in Python instead!
On this topic, the source code and full description for how I addressed the Automation Week UI challenges, using Model-Based Testing and with the traditional sequential approach, can be found at: https://github.com/bitcoder/automation_week_mot
Enjoy