Abbot framework for automated testing of Java GUI components and programs
All materials Copyright © 2002-2004 Timothy Wall, All Rights Reserved

This version 0.13.1 (041111)

FAQ: Frequently Asked Questions, and their answers

Creating Tests

Running Tests

Contributions


When should I use an Abbot script versus a plain old JUnit TestCase?

Usually if you are writing unit tests or tests for small groups of components, you should use a ComponentTestFixture which is derived from junit.framework.TestCase, explicitly invoking actions and assertions on your small number of gui components. See this tutorial for an example of this approach.

Otherwise use scripts, since it lowers the complexity of the overall test and makes it much easier to edit. The script provides easy mnemonics for referenced components. It also abstracts the test into simple actions and assertions. These elements become much less obvious within a long test written entirely in Java code.

How do I test an applet?

Instead of a Launch step, use the Appletviewer step. It will run your applet under appletviewer. You can specify the applet tag attributes as well as parameters for the applet.

I don't see the functions I need.

The Call step is very flexible; you can specify an arbitrary class and invoke a method on it, or you can invoke any method on an existing ComponentTester or Component.

Abbot is also very extensible. You can add custom Step classes that do exactly what you want, custom parsers for translating Strings into custom objects, or add ComponentTester classes for your own components. You can also add methods (actions or assertions) to any of the existing testers and contribute them back to the project. Implementation details are provided in the javadoc description of each of those classes. Most things only require that you make the new class available in the classpath; the framework will pick up the new features automatically, providing you adhere to some simple conventions.

The script language may incorporate a more extensive basis in the future (such as Jython or beanshell), but that hasn't yet proved to be a high priority.

Classpath, classpath, wherefor art though classpath?

There are two methods of specifying the classpath for your application under test.

How can I easily integrate a group of scripts into JUnit? I don't want to have to write a TestCase every time I add a new script.

The class junit.extensions.abbot.ScriptTestSuite has a main method which accepts a list of Abbot script filenames. It will run the standard JUnit text UI TestRunner on each of those scripts.

You can also derive from the ScriptTestSuite or ScriptFixture classes as described in the documentation for those classes to get other types of groupings for scripts, including collecting all scripts from a given directory and recursing into subdirectories, or collecting all scripts matching a particular filename pattern.

My application appears to start, but then nothing happens.

If your main routine doesn't return, or if it performs GUI operations (such as displaying a Dialog) prior to returning, you need to set your Launch step to "threaded". This causes the script to not wait for your main routine to finish and allows it to continue generating events for your code under test.

When running my script I get an InvalidScriptException complaining about a property not recognized for SAX.

Normally it's the "http://apache.org/xml/properties/schema/external-noNamespaceSchemaLocation" property that's not recognized. The reason for this that the Abbot tries to do schema validation on the script on load but the parser used does not support schema validation. This may happen in the case that the classpath contains an entry to an older version of the xerces XML parser. This feature is tested with Xerces 1.4.4 and Xerces 2.4.0 (this is the version delivered with Abbot). Newer version should work also. The solution would be to change the classpath so that the recomended versions of Xerces will be used. If this is for whatever reason not possible in your case it's possible to switch off the vaildation feature by providing the system property -Dabbot.script.validation=false to the VM.

Running tests headless

Sometimes you'd like to be able to run tests without them taking over your computer. Windows systems can run in "service" mode; if you have sshd (which allows remote login to your w32 system) running or can otherwise launch a terminal login session, this session will run with its own desktop which is invisible to the main display. The tests will run in AWT mode, so certain tests (notably drag/drop, which requires native OS events) will not work.

X11-based systems can run under any display, not just that of the logged-in user.

Matching regular expressions

Most expressions within a script can be replaced with a regular expression. For instance, if the title of a window is "Window (FFF)", where "FFF" represents a file and may change, you can change the title attribute of its component reference to "/Window .*/" so that it always matches the variable title.

Matching multiple lines

The regular expression package supports matching of carriage return and newline characters. Within a regular expression, the string "(\r?\n)" will match cross-platform.

How can I contribute to the project?

There are many things that would help move this project along. In addition to simply using it to test your GUI and providing feedback and bugreports to the sourceforge page, you can do any of the following:


  This project's physical resources are supplied by
SourceForge Logo
 

Click to subscribe to java-gui-testing