Why...
For my current customer I wanted to do GUI testing too. I already made unit tests for the most important parts, but with a large code base it is impossible to test all functionality, especially when you have limited time... Because users use the GUI to make orders and do all other stuff, I thought: why not start top-down instead of bottom-up? (I known, normally you should start bottom up, but again: I had limited time). 80% of the time they use 20% of the functionality, so it should be easy to test those parts which are mostly used. And when I click the same buttons in the GUI, a lot of stuff is automatically tested! (black box testing: you don’t know if each function is properly working, you only check the final result, which is okay: better do a coarse test than nothing!).
There are several tools to do GUI automation, but I wanted to program all stuff in Delphi and with DUnit: we have a good framework with a nice data tier and business tier, so it would be a lot easier to use the existing stuff to create for example an order with order lines, check in the database if the order is created with the correct values, and check if the new order is loaded in the GUI, press some buttons, and check the database again.
And also important: I do not want to “pollute” all applications with all DUnit stuff, and I want to test the GUI app “as is”: the same .exe the customer will use.
The idea...
So I started thinking:- we have RemObjects SDK, so I can very easy make a remote call from DUnitTesting.exe to our Client.exe (and start it with a command line option to enable the new remote control)
- we have Delphi 2010 with new RTTI, so I can very easy invoke a function with an array of parameters etc.
- we have HitXML (open source edition), so I can make a simple object tree with properties to sub objects, which are automatically created by HitXML, and I can save/load the whole object with XML. By using the same technique (auto create subobjets using rtti) I can name each object with its property name, and make a back link of the child to the parent. This way I can do a reverse lookup to retrieve a full object path.
Should be possible!
The result...
After some testing and hacking, I have the following proof of concept (stripped version of what we use internally). By the way: I replaced RemObjects SDK with a simple Indy TCP call because not everybody has RemObjects (but with RO it is easier :-) ).I made the following simple objects, with the same name and classnames as the real ones in the remote client (a bit simplified for this blog):
{$METHODINFO ON}In DUnitTesting I can now make the following calls:
TBaseRemoteObject = class
property Owner: TBaseRemoteObject read FOwner;
property Name : string read FName write FName;
end;
TApplication = class(TBaseRemoteObject)
published
frmMain : TfrmMain;
frmTest : TfrmTest;
end;
TForm = class(TBaseRemoteObject);
TFrame = class(TBaseRemoteFrame);
TfrmMain = class(TForm)
published
btnShowModal: TButton;
end;
TfrmTest = class(TForm)
published
btnOk: TButton;
btnCancel: TButton;
framTest1: TframTest;
end;
TframTest = class(TFrame )
published
Button1: TButton;
Edit1: TEdit;
end;
TButton = class(TBaseRemoteObject)
public
procedure Click;
end;
TEdit = class(TBaseRemoteObject)
public
property Text : string read GetText write SetText;
end;
RemoteApp.frmMain.btnShowModal.Click; //create modal form frmTest RemoteApp.frmTest.framTest1.Edit1.Text := 'test'; //set textCheckEqualsString( RemoteApp.frmTest.framTest1.Edit1.Text, 'test' ); //check textThis would result in clicking “btnShowModal” of the main form, which will do a .ShowModal of “frmTest” (this is programmed in the remote client). All forms are normally accessible via the “Forms.Application” object or “Screen.Forms” array, so we can find “frmTest” in the remote root (RemoteApp). In this form, we have a frame “framTest1” with an editbox “Edit1”. I made a “Text” property which does a remote call in “SetText” and “GetText” to read and write the text:
procedure TEdit.SetText(const Value: string);How does it work...
begin
TRemoteControlExecutor.Execute(Self, 'Text', [Value]); //set “text” property with value
end;
function TEdit.GetText: string;
begin
Result := TRemoteControlExecutor.Execute(Self, 'Text', []).AsString;
end;
An explanation of how the reading and writing of “Edit.Text” works internally:
The “TRemoteControlExecutor” does a reverse lookup of “Self” (in this case “Edit1”) to get the full path (“frmTest.framTest1.Edit1”). This is send to the remote client, including the function or property we want to read/write (“Text”) and the parameters for it (explained below).
When the remote client receives the call, it does a “TThread.Synchronize” to the mainthread. Then it searches for the form “frmTest”: is it “Screen.ActiveForm”, or somewhere in “Screen.Forms[]” or using “Application.FindComponent()”? When found, it does a recursive lookup for “framTest1” and “Edit1”. After that, it searches for a function named “Text” in component “Edit1” using the Delphi 2010+ rtti. In this case it won’t find such a function, so it searches for a property, and yes: property “Text” does exist :-). Now, a simple trick is done to determine a read or write of a property: if we have 1 parameter it is a write, if we have no parameters it is a read. The rest is easy with the new rtti: .Invoke() for a function, and SetValue()/GetValue() for properties. The result is written and send back to the caller.
This way you can very easy control a remote client! Seems nice and straight forward to me, isn’t it?
The TButton.Click is done using WM_LBUTTONDOWN + WM_LBUTTONUP, instead of executing the .Click function: otherwise when a .ShowModal is done we will get a “remote lock”!
I also had to do an “Application.OnIdle” check, because creating and painting can take some time, and when a remote message is executed as the first message after create, it can give some strange results.
Note: by using the same classnames, it is easy to set up to lightweight remote facade proxy classes: you can just copy the first part of the form, for example:
type
TfrmMain = class(TForm)
btnShowModal: TButton;
btnShowFloating: TButton;
procedure btnShowModalClick(Sender: TObject);
procedure btnShowFloatingClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
Of course, this can automated if needed... :-)
And by the way: by using “Application.OnMessage” and “Application.OnActionExecute” I can record the clicked buttons and actions (WM_LBUTTONDOWN, find control under mouse, etc). Not included in this demo, but can post another demo if needed?
I extended the XMLTestRunner.pas with the duration of each test, very handy to see how long each test functions takes!
With TCP you can also control multiple (infinite?) clients in a whole network, to do a “massive” test :-).
See the code and try it yourself! What do you think about it? A good way to do GUI testing or are there better ways? Please let me know!
http://code.google.com/p/asmprofiler/source/browse/#svn%2Ftrunk%2F-Other-%2FRemoteControl
