This page contains a Flash digital edition of a book.
22 | Feature

Open source testing tools TABLE 2 The table above shows a few

examples of MonkeyTalk component types and their platform-specific counterparts. Note that iOS’s ‘UISegmentedControl’

maps to MonkeyTalk ‘RadioButtons’. Mappings like these increase the portability of MonkeyTalk scripts for applications that are “logically equivalent” on multiple platforms, without necessarily being identical. In addition to facilitating cross-

platform scripting, MonkeyTalk’s logical components allow scripters with no knowledge of underlying user interface technologies to learn one consistent dialect that can be used for scripting any user interface on any platform.

As object-oriented as you wanna be While MonkeyTalk can be used without any understanding of object-oriented programming, it does provide simple object-oriented mechanisms including inheritance, method overriding, and polymorphism that make it simpler to understand and use, even by non-programmers. Additionally, MonkeyTalk’s object-oriented structure allows it to map naturally to any modern user interface framework or common language API, since virtually all are themselves object-oriented. More on that later. Like native user interface frameworks,

MonkeyTalk’s platform-independent components are organised into a component hierarchy, and actions supported by a parent component are inherited by its subclasses. For example, the root user interface

component in MonkeyTalk is called ‘View’, and it includes basic actions like ‘tap’ and ‘enterText’. A MonkeyTalk Input component inherits the ‘tap’ and ‘enterText’ action from View, and adds an additional ‘clear’ action that blanks out an input field. The View component type also

provides various ‘verify’ commands that allow scripts to test that actual component values match expected values or patterns, and these actions are likewise inherited by all component types. It is common for developers to subclass standard user interface

TEST | August 2012

components to create custom application behaviour, and MonkeyTalk automation is inherited by custom classes. Thus, the command: Button OK tap will tap on a native button or any button subclass, for example, “MyFancyButton”, within the application under test. Similarly, since View is the root

component type, a command such as:

View OK tap will tap on the first component called “OK”, regardless of component type.

Identifying with a monkey While some other popular UI testing frameworks identify component through the use of search expressions with varying levels of complexity, MonkeyTalk relies on the fact that components typically have ‘naturally identifying’ properties that serve as unique identifiers. These identifiers are often visual, for example, the label on a button, or its tool tip, but others, such as properties like “id” or ‘name’ are oftentimes invisible to users of an application, although typically easy to discover through inspection tools (like Firebug or the MonkeyTalk IDE’s Tree Viewer), or simply through recording an interaction with a component. MonkeyTalk defines the notion of a

‘monkeyId’ in order to identify specific instances of a component type. The interpretation of a monkeyId is platform and component-type-specific, but in general consists of matching the value against each of the various properties that naturally identify components of some type. For example, for HTML/ Web applications, the monkeyId is compared against several properties including the HTML element’s id, name, title, and text value to see if any one of them matches. In less common cases where a component has no unique value for any of its natural identifiers, monkeyId’s can be subscripted, so if for example there were multiple OK buttons on some screen, you could specify which one by subscripting the monkeyId with parentheses like this: Button OK(2) tap Additionally, an asterisk (*) is a wildcard identifier so that the resulting command matches on component type only,

which is useful in situations where there is only one component of a particular type currently displayed, so you could, for example, say: Button * Tap This command would click on the first button found on the screen, regardless of its id values. We could also specify a particular Button by index (stating with one), by specifying an ‘ordinal id’ of the form #n, for example: Button #2 Tap At recording time, the platform’s Recording Agent determines which value to use as a monkeyId. This is typically determined by first examining the most logical identifier, for example the label on the button, and if it is blank continuing to search the other properties until a non-blank one is found. If no value is found, then the recording agent returns an ordinal id. At playback time, it is the responsible

of a platform’s Playback Agent to search the currently displayed UI components to find a match.

If at first you don’t succeed An important aspect of automation scripting is the ability to synchronise script execution with that of the application under test. Consider again the simple login test script. Input username enterText user01 Input password enterText mysecret Button Login tap Label * verify “Welcome, user01” Assume that the application takes a

few seconds to process the login before displaying the welcome message. If the MonkeyTalk script tries to verify the welcome message before it is actually displayed, then the script will fail. MonkeyTalk commands are retried

until they succeed or timeout, and default timeout intervals can be specified to the MonkeyTalk Runner. MonkeyTalk also allows the timeout to be lengthened or shortened for any command by specifying a new timeout value in a “command modifier”. For example: Label * verify “Welcome, user01” %timeout=5000 The command above will retry until the label is displayed with the expected value, or until five seconds (5000 milliseconds) has elapsed. Similarly, the command: Button OK tap %timeout=5000 will wait for up to five seconds for the OK button to be displayed before failing.

Any language can MonkeyTalk Most test scripts step through a sequence of perform-action-and-

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52