Abbot framework for automated testing of Java GUI
components and programs
All materials Copyright © 2002
Timothy Wall,
All Rights Reserved
This version 0.9.0 (030527)
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?
Run your applet under AppletViewer. You need to specify an HTML page for
AppletViewer to load, and indicate your applet class in the Abbot script. The
sample HTML and
Abbot script are provided as templates.
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, or add ComponentTester classes or add methods to existing ones. 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.
You can also add to the user actions provided by extending the
ComponentTester class.
Details are provided in the description of that class.
Classpath, classpath, wherefor art though classpath?
There are two methods of specifying the classpath for your application
under test.
- Specify the classpath in the script Launch step.
A custom class loader (abbot.script.DynamicClassLoader) will be used to load
your classes from the classpath you specify. Relative paths are evaluated
based on the current directory (user.dir). If your code under test uses
ClassLoader.getSystemClassLoader to obtain the "current" class loader, you
should fix the code to use Class.getClassLoader or
Thread.getContextClassLoader instead.
- Pass the classpath to the VM on startup.
This method is not preferred. Don't do it. Only the framework classpath
(i.e. abbot.jar) belongs here.
There are some cases where you might want to use this method (such as when you
need to dynamically generate the classpath for a number of different runs).
If so, then the classpath in the launch step should be left blank, and the
launch step should be set to fork="true", unless you don't care about
reloading all classes on each test run.
- Pass the full classpath to the Launch step, and part of the classpath
to the VM on startup.
Sometimes an application will report that it cannot load resources that it can
find when not running under the Abbot framework. One common cause is that
ClassLoader.getSystemClassLoader() is often used when
getClass().getClassLoader() should really be used instead. The class loader
returned by the former is the class loader for the Abbot framework (which uses
the classpath passed to the VM on startup). In the latter case, the class
loader is that created by the Launch step for your app. You can work around
the problem by either a) changing the code to be correct or b)
putting the path to your resources in the classpath of the startup VM.
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.
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:
- Write a ComponentTester class for a component that doesn't yet have one,
or add more accessors and/or actions to existing ones that need more.
- Write a Recorder class for a component that doesn't yet have one. The
recorder should capture those actions exported by the corresponding
ComponentTester class.
- Write a user's manual for the editor.
- Contribute your general GUI testing experience to the
yahoo discussion group. Note that this group is for discussion of general
GUI testing issues and practices; questions specific to Abbot should be
directed to the Abbot help forum on
SourceForge.