Look up a component, usually by some obvious attribute like its label.
Perform some user action on it, e.g. "click" or "select row".
Scripts vs compiled code
How can I test a GUI prior to writing code? One alternative (and useful in certain cases) isdeveloping a mockup in a RAD tool. Unfortunately, the usefulness is relatively short-lived; it'snot really possible (at this point in time) to automatically generate a very interesting interface. If your entire interface consists of buttons and forms, you may not really need a gui tester anyway.Mockups don't convert well to tests for the actual developed code, and RAD tool output usuallyrequires some hand modification afterwards.What a test script could plainly describe the GUI components of interest, and simply describe theactions to take on those components? Providing you know the basic building blocks, you can editthe scripts by hand or if you don't know the building blocks, in a script editor. No compilationnecessary, which speeds development and maintenance of tests.I wanted scripts to be hand-editable, with no separate compilation step. I wanted to be able todrop scripts into directory hierarchies as needed, and have the test framework pick them upautomatically, similar to how JUnit auto-generates test cases.
How to Test
One issue in defining a GUI test is that you need to map from a semantic action (select the seconditem in the records table) onto a programmatic action (myTable.setSelectedIndex(1)). Thiscomprises two separate problems. First, the target of the action, "records table", must besomehow translated into an actual code object. Second, the semantic event "select the seconditem" must be translated into a programmatic action on that code object.
There are many methods of identifying a component in a GUI hierarchy. We want the tests to beflexible enough to not break simply because another button or panel was added to the GUI layout.
Java provides for naming components, but since no one ever namesthem, this method of identification is mostly useless. Worse, some auto-generatedcomponents (frames for otherwise frameless windows, windows for popup menus, andmost dialog instantiations) have auto-generated names, which aren't particularly helpful,or even downright misleading if components get created in a different order thanexpected.
Position in hierarchy
This method guarantess a unique match, but also guarantees your script will break when that hierarchy changes, even for otherwise trivial modifications(like inserting a scrollpane). Each component would need to store its parent reference andindex within that parent. Note that this implies each parent reference might need to storethe same information for itself.
Parent window title
This is useful as a first-pass discriminator in multi-windowapplications.
This helps discriminate from the available components list, but is notlikely sufficient on its own to identify a component.