“Object not found.”
That’s what a GUI test tool is likely to log when an object is, well, not found. And many times no useful additional information — context — is available.
But there are situations when context is available, but usually not reported: and that situation is when some sort of selection fails.
- Menu item not found.
- Tree view or cascaded menu item not found.
- Radio button not found.
- Select list option not found.
In these situations, it’s very useful for the test log to report what was found:
- Menu: items found in the menu and the item not found.
- Tree view or cascaded menu: nesting-level of the failure, items found at that level, the item not found, and the items successfully found farther up the tree.
- Radio button: buttons found in the set and the item not found.
- Select list option: options found in the list and the option not found.
This can really matter.
Suppose, for example, that the spelling (or even the casing) of an item is changed. You might have to breakpoint the test and run it for minutes, just to see what’s going on. But if the context of the failure — the items that were found — are logged, you’d immediately see what’s wrong.
So how to do this? In the GUI encapsulator, discussed in post
“Encapsulate the GUI Tool?”
For example, suppose in the GUI encapsulator you have a method whose job it is to select a given option from a given select list:
- Create a new method that logs all the options in a given select list.
- There will already be code to search for the relevant control. Around that code, place a
- In the
catchblock, call the new logger method, then re-raise the exception.
Now when a desired select option is not found, the log will contain all the items that were in the list, which you can now examine without re-running the test. Time-saver!
Try it! You’ll like it!