The SwingRobot test tool provided by Dr. Dalbey is for creating and running test scripts for Java Swing applications. It allows you to create specialized test scripts which simulate keyboard and mouse operations. The scripts can then be run automatically by the robot, saving hours of laborious manual testing.

SwingRobot is an enhancement to the java.awt.Robot class.  You might find it helpful to read this first: Automated GUI Testing with Java.AWT.Robot.

Here is the SwingRobot.java source code.

Note that the SwingRobot belongs to a package TestTools.

Command Syntax

java  TestTools.SwingRobot  <application class>  <testscript filename>
    <application class> is the name of the compiled class of your application program you desire to test.
    <testscript filename> is the name of the text file containing the script command that you want to use as input to your application.  By convention, the script file extension is .rsf  (for "robot script file").

Example:
    java  TestTools.SwingRobot  MyApp  TestScript.rsf

When started, the SwingRobot will load your application, call the main() method, and then execute all the commands in the script file.  If the class doesn't have a main() method, SwingRobot will call the default constructor for the class.  So be sure that the constructor uses "setVisible" or whatever is necessary to display your GUI.

If you want to pass command line arguments to your main() method, place them in a file named AUT.properties in the folder where the test will be run. 
Example AUT.properties file:
commandline= --players=2

Examples

Example Robot Script File:  TestScriptDemo.rsf
This demo script file includes a list of all legal script commands shown at the top. (Lines beginning with two dashes are comments).

Here is a complete example:
    SystemTests.zip [232K]         This example from FishBowlGames shows how to organize the folders for the system tests and TestTools.
 

Of course, the hard part is that you need to somehow verify that running the application produced the expected results.  The robot can't help with this.  The robot will only run the program for you with the input you provide.  You need to determine how a correctly executing program should behave.  For example, by looking at the data files produced.  Then you need to compare the actual results against an "oracle" the contains the predicted results.

Tips:

• Don't use mouse moves!  It's extremely tedious to determine the proper coordinates to give the robot, and the coordinates may easily change if the GUI layout is revised or the screen resolution changes.  Instead assign key mnemonics to buttons and menus and tell the robot to use the appropriate key combination to press the button.  You may also take advantage of tab ordering to tab between components.
• If your app is distributed and you want to run several clients in different windows, the "start" command in Windows XP is very handy.  Type "HELP START" at the command line to see the help documentation.  Write a batch file which "starts" the different windows, then start the robot and have it ALT-tab between windows.
  
• Don't end your application with System.exit(0) because that will halt the robot before it has a chance to close up gracefully. This may cause odd behavior resulting from the OS thinking the ALT key is still depressed. You can terminate your GUI with dispose().