It’s pretty well established that a GUI test library should encapsulate the web pages. See Keep Your Page Objects DRY.
But encapsulate the GUI tool itself?
First off, what does it mean to encapsulate the GUI tool? It means that only one class makes direct calls to methods in the GUI tool. That class “wraps” methods in the GUI tool, performing any desired actions before and after calling into the tool. All other classes, including the page-object classes, call into the wrapper class, and not into the GUI tool’s classes.
How does this matter? Let me count the ways.
I’ve recently worked with a GUI tool that, when it could not locate a control, simply raised an exception saying “Object not found,” together with the search criteria it used.
On any such failure, a method should return something useful. Often this can be what it did find:
- Select list option not found: return the options found in the list.
- Treeview or cascading menu item not found: return the items found in the tree or menu.
- Radio button not found: return the labels of the buttons found.
This information can save lots of time — time not spent running the test up to the point of failure, just to see what’s there.
Btw, in my case I’ve named the class
WebGui, because my GUI tool also has an interface to Windows applications.
So in my class
WebGui, there are methods that log diagnostic messages. Method
WebGui.SelectOption, for example, first calls the GUI tool’s method to select the option. If the selection is not found,
WebGui.SelectOption logs an error together with all the options that were found.
This can mean a big time saving when, for example, the difference is just a spelling change.
Consider whether a wrapper method can return something useful. For a setter method, it’s always useful to return the previous value, to allow the value to be restored. See Getters and Setters.
In my method
OpenHyperlink, I’m returning the URL of the opened link.
You can add instrumentation to the wrappers, so that useful information gets captured in the test log. One implementation is to use an environment variable to control the verbosity of the logging done in the wrappers. By setting the environment variable, you can “turn on the rally lights” in the test, and get much more detail than usual.
I also like to add timestamps and durations to the logged calls, which can help identify trouble spots in the tests.
You can put options onto the wrapper methods that are lacking in the GUI tool:
- Retry an action some number of times, or for some time period.
- Confirm that a setter method actually worked (raise exception if not).
- Optionally use a strategy different from the default strategy; for example, send keystrokes instead of clicking.
The point here is not that you’ll want to use all of these ideas. The point is that if you encapsulate the GUI tool, you’ve left open the door to doing so.