Modeling UI for automated GUI testing

If you’ve been following my blog recently then you’re already familiar with the name Zombie and that it’s based on this patent. The part that I’m going to touch on in this post is relates to this sentence from the “Summary of the Invention”:

"The system includes a Generic Element Models (GEMs) library,
Application-specific Testing Models (ATMs), a Resource Database, one or
more Model Generators..."

Like VCL one of the most powerful features of Zombie is its set of core GEM classes. A GEM is a class that provides the ability to inspect its VCL counterpart at runtime using RTTI as well a mechanism similar to class helpers as well as interact with the component via the mouse and keyboard. However, just like individual VCL components GEMs really aren’t all that useful unless you combine them just like you do when you drop VCL components onto the form designer. Since GEMs have no visual representation themselves we turn to model generators to do the heavy lifting and produce classes that mirror entire VCL Forms using various GEMs to represent the components on the form. Here is an example of a simple VCL form and what a model for it might look like:

type
TMyForm = class(TForm)
MessageText: TLabel;
Yes: TButton;
No: TButton;
Cancel: TButton;
end;
type
TMyFormModel = class(TBaseDlg)
MessageText: TLabelGem;
Yes: TButtonGem;
No: TButtonGem;
Cancel: TButtonGem;
constructor Connect; override;
procedure Init; override;
end;

Given the above model you could use it as follows:

var
AMyFormModel: TMyFormModel;
begin
AMyFormModel := TMyFormModel.Connect;
try
Writeln(AMyFormModel.MessageText.Caption);
AMyFormModel.Yes.Click;
finally
AMyFormModel.Free;
end;
end;

This example illustrates the inspect capabilities of a GEM with code like MessageText.Caption as well as the automation capability using methods like Yes.Click where the click method internally inspects the size and location of the button and correctly determines where mouse down/up events need to occur to execute a mouse click. The implication here is that models are resolution independent and therefore suites written with Zombie can run on any resolution which is exactly the case.

We use a model generator for the IDE which generates roughly 1000 models of various forms/frames from DFMs used throughout the product. These models reflect any Visual Form Inheritance used within the forms and therefore provide a deep toolbox for suite developers to leverage and drive nearly all aspects of the IDE.

3 thoughts on “Modeling UI for automated GUI testing

  1. Wow, I’ve been searching for something just like this for ages. So… Is Zombie ever going to be available beyond the walls of Borland? If not, could you give a quick rundown of why not, and what our alternatives are to getting something like Zombie going (without the 5 years R & D)?
    Cheers.

Comments are closed.