Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
5Activity
0 of .
Results for:
No results containing your search query
P. 1
Elements Of GUI

Elements Of GUI

Ratings: (0)|Views: 651|Likes:
Published by Banhi

More info:

Published by: Banhi on Apr 02, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

09/03/2010

pdf

text

original

 
The Pain (Problems and Goals)
On the subject of why testing is so important, I won't repeat here what has been aptly described inTest Infected. If you haven't read that document, please do so before proceeding here.Often a developer will want to make some optimizations to a piece of code on which a lot of user-interface behavior depends. Sure, the new table sorter will be ten times faster and more memoryefficient, but are you sure the changes won't affect the report generator? Run the tests and findout. A developer is much more likely to run a test that has encapsulated how to set up and test areport than he is to launch the application by hand and try to track down who knows how to dothat particular test.To test a GUI, you need a reliable method of finding components of interest, clicking buttons,selecting cells in a table, dragging things about. If you've ever used java.awt.Robot, you knowthat you need A Better 'Bot in order to perform any user-level actions. The events the Robot provides are like assembly language for GUI testing. To facilitate and encourage testing, you needa higher-level representation.Describing expected behavior 
before
writing the code can clarify the developer's goals and avoidoverbuilding useless feature sets. This principle applies to GUI component development as wellas composite GUI development, since the process of writing tests against the API can elucidateand clarify what is required from the client/user point of view.
GUI Design
First of all, any GUI component should provide a public API which can be invoked in the samemanner via a system user event or programmatically. Keep this in mind when writing newcomponents. In the case of Java's Swing components, the event handling is mixed up withcomplex component behavior triggers in the Look and Feel code. It's not possible to execute thesame code paths without triggering the originating events. A better design would be to have theLook and Feel code simply translate arbitrary, platform-specific event sequences into public APIcalls provided by the underlying component. Such a design enables the component to be operatedequally as well by code, whether for accessibility or testing purposes.
GUI Testing
GUIs need testing. Contrary to some opinion, the problem is not always (or even commonly)solvable by making the GUI as stupid as possible. GUIs that are sufficiently simple to not requiretesting are also uninteresting, so they do not play into this discussion. Any GUI of sufficientutility will have some level of complexity, and even if that complexity is limited to listeners (coderesponding to GUI changes) and updates (GUI listening to code state changes), those hookupsneed to be verified.Getting developers to test is not easy, especially if the testing itself requires additional learning.Developers will not want to learn the details of specific application procedures when it has no bearing on their immediate work, nor should they have to. If I'm working on a pie chart graph, Idon't really want to know the details of connecting to the database and making queries simply toget an environment set up for testing. So the framework for testing GUIs should require no morespecial knowledge than you might need to use the GUI manually. That means
 
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.
Tracking components
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.
Component Names
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.
Component class
This helps discriminate from the available components list, but is notlikely sufficient on its own to identify a component.

Activity (5)

You've already reviewed this. Edit your review.
1 hundred reads
kamit64 liked this
Ameya Gharote liked this
Ameya Gharote liked this
lowell_pd liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->