This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: How to write Acceptance Tests for GUI Applications
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
The way we usually handle this is with a layered
architecture. There are three layers: the Graphical
UI, the Logical UI, and the rest of the application.
(The rest of the application is probably also layered,
but it's not particularly interesting at the moment, so
I'm ignoring it.)[...]
The GUI is a thin facade on top of the LUI. If there
is a button on the GUI, there is a method in the LUI
that gets called when the button is pressed. If a field
is to be displayed on the GUI, there is a method in
the LUI that is queried for the contents of the field.
If the GUI needs to be notified of something so the
screen can be updated, there is a method in the LUI
that will accept a callback. And so forth.
The acceptance test deals with the Logical UI. Since
the Logical UI is isomorphic to what appears on the
screen, we don't lose anything except the hassle of
trying to test the application through the GUI.
When using Cocoa/NextStep, you specify the LUI methods to call in InterfaceBuilder [for example, if I recall correctly, a button in a dialog calls any method you want on the class you designate as the "target", instead of "sending an event"], so in that environment you actually do very little "GUI" programming - in the sense of writing code.
My strategy for acceptance testing GUI apps has been to make the App scriptable. Support AppleScript access to your domain and GUI objects on MacOS. On Windows, we made appropriate objects COM accessible, and thus could write acceptance tests in JScript of VBScript (or almost any other scripting language on Windows.)
Previous Topic
