A layer below the GUI

I wanted to expand on the main point of my last post – specifically on what a “layer below the GUI” means. All I mean is – don’t write automation that interacts with the GUI directly – instead, write automation that tests using an object model, or another method of testing the logic under the UI.

For example, code like this:

type_text("My Name");

Or this c# code:

Process wordApp = Process.Start("Winword.exe");
if (wordApp.WaitForInputIdle(1000))
    SendKeys.SendWait("This is input to WinWord");
    SendKeys.SendWait("^a"); // send ctrl+a (select all text)
    SendKeys.SendWait("^b"); // send ctrl + b (make text bold)

…is usually a waste of time (note – I made up the first code example based on what I remember about QTP). Why not write automation that tests the functionality at a level that can be more robust?

Many apps have an object model that makes stuff like this a lot easier. For example:

Object template = Type.Missing;
Object newTemplate = Type.Missing;
Object docType = Type.Missing;
Object visible = Type.Missing;

Word.Application wordApp = new Word.Application();
Word.Document wordDoc = new Word.Document();
wordApp.Visible = true;
// the following line is equivalent to selecting File, and then New
// to create a new document based on Normal.dot.
wordDoc = wordApp.Documents.Add(ref template, ref newTemplate, 
ref docType, ref visible); wordDoc.Selection.TypeText(“This is input to WinWord”); wordDoc.Selection.WholeStory(); wordDoc.Selection.Font.Bold = 1;

Same functionality, except now it will run on any language version of word, and may even keep working in the future. Many automation frameworks allow you to write similar code, but many testers just default to the fragile implementations.

If you have any other way to automatically test the functionality without going through the GUI, do that. If you’re testing an application that doesn’t have an object model (it’s certainly not a requirement), you can access windows controls through the IAccessible interface (it’s handy for much more than accessibility) – you can also ask your developers to implement IAccessible for any custom controls. This way, you can test the functionality of your GUI even if the UI is completely rearranged and the default language is changed to pig latin.

One final point – I’m not saying that you shouldn’t test your GUI at all – it’s just probably a better use of your time to focus your automation efforts somewhere other than button clicks and text. Most UI automation is probably better done manually. Once your product ships a few versions, and you’re up to several SKUs and dozens of languages, you can begin to justify UI automation – but by then, you’ve probably already realized that you need to write robust UI automation…or you’re about to.

Comments (4)
  1. world.com.ru says:

    Very important documentation. Great work. Thanks a lot.

  2. Halperinko says:

    Great post,

    And not only it will be more robust, most likely it will run much faster – as GUI Automation tools take a lot of time to seek different objects.

    As to multilingual GUI tests, one should better test the files translating from object names into specific labels in each language (if labels are not hardcoded – in that case just shoot the developer 🙂 )

    A simple script + MS-Word Dictionary can do the trick (Search for spelling mistakes, length diffrences, missing translation and etc.)


  3. TheUiGuy says:

    Hello! I’m only a month too late, but I just read this post. Continuing the discussion, there is just one enormous pre-condition required for the test you pointed out above for web UI environments, which is where much of this is sorely lacking. (sorry if thats not your point, but bare with me)

    And that is… drumroll

    …that the UI (or front end) environment in question (the templates, js files, css, etc…) has been structured in any meaningful way that makes such testing possible.

    Over the course of 10 years of abuse by various companies like Netscape, Sun, Microsoft, each with their own products and standards… evolving over time… with front end developers embracing JavaScript with little or no development experience… and without anyone having much foresight to code the front end properly… you have all kinds of mutations of should be a homogenous and trustworthy code structure, but isn’t.

    I would pay good money to see one person at one company, who, when netscape had its l

    "layers" and "document.all" was browser detection, actually had the foresight required to design the front end in such a way as to be modular and testable for their 3rd party products. Most people who fell face-first into the front end did not come from development backgrounds, or just didn’t want to bother.

    What you have written in this blog is definitely a dream of mine. You have nailed the real useful way to automate tests…

    However, even where I work, (using myself as an example) I am dealing with code that reflects the past 8 years of my growth as a developer. When I look at what I thought was good LAST YEAR, let alone 6 years ago, it makes me nuts to consider how long it would take to get that code into any form that could be tested in this fashion. It’s taken me all this time to finally write very elegant, stable, scalable, readable code. And i still think I’ve just begun.

    So yes, for many products this is a feasible and intelligent solution… but for many web-based applications with the crazy web developers who’ve put up with this crap of changing standards and incompatibilities: chaos is the way of our world and its only now (and I mean, as of a few weeks ago) that we even have good development tools (like Msft Visual Studio, or some of the finer Yslow type apps).

    I’m not sure this is any kind of disagreement, but rather just a rant. Essentially, its frustrating.

Comments are closed.

Skip to main content