About/Contact

Steve Trefethen

Steve Trefethen is a Director of Engineering at Reply. Contact me

View my LinkedIn profile


Powered by discountASP.NET
referal ID: sdtref
Why recommend discountASP.NET?
$720 in referrals so far!


Calendar

<<  February 2012  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
2728291234
567891011

View posts in large calendar

Disclaimer

The posts on this weblog are provided AS IS with no warranties, and confer no rights. The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.



Modeling UI for automated GUI testing

October 24 2006 4:10AM
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.
FacebookDel.icio.usDigg It!

Comments (3) -

10/25/2006 2:46:42 PM #

Interesting stuff, Steve.

How does the GEM actually use .Connect() to link with the IDE being tested?

Eric Fortier

10/25/2006 8:38:33 PM #

Hi Eric,
  I'll get to the answer for your question with an upcoming blog post so hang tight!

-Steve

Steve Trefethen

10/26/2006 6:53:12 AM #

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.

Graham Wood

Add comment




  Country flag
biuquote
  • Comment
  • Preview
Loading