Model-based Testing II: The GUIening

This post has 1216 words. Reading it will take approximately 6 minutes.

The modeling business is all about looks.  Delicate lines, color composition, presentation all coming together.  Ok, I’m done with a bad attempt at a bad analogy. Reports of my death are greatly exaggerated.  As is the existence of such rumors.  While I’ve been quiet about my MBT Workbench, this is in part because I have been busy with my studies and checking out the recent Java 9, Spring 5, and JUnit Jupiter releases.  I have also been working on a couple of posts about Bitcoin, because I also want all those hype ad-clicks.
Not all has been entirely dead; I have been moving the MBT Workbench towards these and in the process ditched my own Observable Collections library for the Glazed Lists library (Java 9 deprecates the Observer/Observable structure I relied on in my library).  I have also been working on the reporting feature, including storing test results in a database.  I’ll write a post about this… sometime(s).  I also still have a video demo in the pipeline, which will be out Real Soon Now(tm) (I have made an outline of a script, so I’m like 99% done – I just need to record, edit, and upload it). It has not been a secret, that I want to take my MBT Workbench beyond API testing.  I already have a full 3 lines design document for extending it to also handle database testing, and an abstract idea of how to extend the operation from single interactions to more complex scenarios (e.g., invoke a web-service, carry over a value to another web-service and finish off by checking something has been registered in the database).  I also have a design document for taking the MBT Workbench in the direction of GUI testing.  for a while, it has just been 8 letters 1 line with 2 question marks, 3 words, one meaning. Earlier this week, we had a presentation about GUI testing at work.  It was based Behavior-Driven Development (BDD; it’s basically Test-Driven Development culturally appropriating the BDD abbreviation from the model-checking community) and using a trifecta of tools: Cucumber JVM, Serenity BDD, and Selenium.  I was not too interested in the specifics – there will be new frameworks claiming to have solved testing every day – but a thing really stuck with me: the presented approach made a representation of the user-interface providing methods for invoking widgets in a logical manner (“click register button”) and inspecting page elements (“inspect last row of customer table”).
If you’re familiar with my meta-model for model-based testing, you might realize that this user-interface abstraction, is very similar to my input and output mappings, the input mapping corresponding to the methods for invoking widgets and the output mapping corresponding to the methods for inspecting elements.  What is more, I believe the same approach I use to assist users in generating input and output mappings in the MBT Workbench can be translated almost directly to inspecting a web-page and allowing users to indicate which elements are interesting and map them to input/output variables. If you are know standard model-checking, you might also recognize the duality between state and transitions/events.  It is explicit in the definition of finite automata/transition systems/Kripke structures, the go-to semantic foundation for many model-checking techniques.  The widgets I can interact with correspond to events and the elements I can inspect correspond to (observable atomic propositions of) states.  This got me all excited, because I am that kind of person who becomes excited about things like this. It turns out, I have already worked with formalisms extremely suitable for this kind of thing.  Back in 2004 I was visiting Kim Guldstrand Larsen the University of Aalborg.  At the time, one of the topics his group were working on was timed games, and extension of their regular timed automata and realized in the tool Uppaal TIGA, a specialized version of their tool Uppaal for analyzing such systems.
(Timed) game automata split events into two groups: the controllable and the uncontrollable ones.  The intuition is that a system of two players describes the game in entirety and one player controls the controllable events, and the other(s) the uncontrollable ones.  The question is whether the player with the controllable events can get to a “winning” state regardless of which uncontrollable actions their opponent selects.  consider an example of a game of tic-tac-toe, where the controllable actions comprise putting an X on the board, and the uncontrollable ones of putting an O on the board.  Can the player get three Xes in a row without the opponent getting three Os in a row, regardless of how well the opponent plays? This is of course interesting to game theorists (yawn), but aside from being an interesting model-checking question, it also has applications to interaction with services; in fact, I even did a couple of papers on this: [bibtex file=workshops.bib key=gameanimation,gcpn] Here, the idea is that user behavior is controllable while application behavior is not.  In my work, I was mostly focusing on using that to visualize application behavior, but I am certain I can adapt this is provide a unified model of user behavior and application behavior.  The details are not entirely clear to me yet, but I am certain I’ll get there. There is some related work in other disciplines; for example, the business process modeling community likes to use tau steps to represent actions that “just happen” without interaction from the user.  Tau transitions in BPM models is the same as epsilon transitions in non-deterministic finite automata, which model that some action can occur.  The entire analysis is in fact very similar to the subset construction used to used to turn a non-deterministic automaton into a deterministic one accepting the same language. I will probably just adapt the notion of controllable/uncontrollable actions to the decision trees and flow-chart notation I already use.  I might need some notion of non-deterministic choice and probably some notion of modules. The current models just model a single interaction; they are essentially just events with an implicit start and end-state.  These events are actually tau transitions or uncontrollable actions: the user has no influence on what happens in the computation, and we need another level on top of this to represent the flow of scenarios.  We can think of the current tests as atoms: sometimes they can stand alone, but sometimes they are combined with others to create new compounds. I don’t have an exact plan for this “molecular” level yet.  I could easily see checking BDD rules on the model or on the system.  I would also like a very simple transition-system like description of the interactions between different “pages” in the GUI.  This could, e.g., be related to how Spring Webflow describes more complex interactions as guarded transition systems. The next step is that I will do a bit of refactoring of the MBT Workbench to generalize some of the terminology to make room for some of the new concepts and then I’ll add in a Selenium wrapper that can extract and abstract web-pages.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.