Commands are the way that programmers extend the Exactor framework to automate acceptance tests against their own applications.
A command is created by extending the framework class com.exoftware.exactor.Command.
By default the command will fail with a message indicating that no implementation has been provided.
To make a command do something useful the programmer must override the execute method to perform whatever actions or checks are required by the command.
The framework Command class extends JUnit's junit.framework.Assert, therefore all of the methods of Assert are available for use in commands. These asserts can be used to perform any required checks.
An assertion failure results in an AssertionFailedError being thrown. The framework catches these errors and reports them as failures in the script.
Any other exceptions are caught by the framework and reported as errors in the script.
Commands will normally require additional information to do anything useful. This additional information is typically supplied to the command as parameters in the test script.
The Command class provides access to the parameters supplied to the command in the script using the getParameter method, which takes a zero based integer index indicating the position of the parameter to access.
The Parameter class returned has methods, intValue, doubleValue and booleanValue to convert parameters supplied to the script into various primitive types.
It may be necessary for a number of commands to share information to carry out their actions.
The framework provides two levels of context that commands can use to store values that can be accessed by other commands.
The Script containing the command (accessable via the getScript method on Command) has a context map that is available to all commands in the same script.
The ExecutionSet has a context map that is available to all commands in all scripts in a particular run, i.e. a global context.
The context maps are simply instances of java.util.Map accessed by the getContext methods on Script and ExecutionSet.
If you find that your scripts repeat the same sequence of commands you can create a composite command that contains the repeated commands and call the composite command in your scripts.
A composite command is simply a script file with the usual .act extension located on the CLASSPATH.
A composite command is referenced by the name of the .act file, excluding the extension. For example a compsite command defined in the file SomeCommand.act would be referenced by a script as SomeCommand.
As part of your project build process you may need to explicitly copy .act files into a location specified on the CLASSPATH
Composite commands may require parameters just as basic commands do.
Parameters are supplied to the composite in the same way as a basic command by putting them after the command name in the script file.
For the composite to make use of the parameters the composite command can use placeholder parameters to refer to the positional index of the supplied script parameters.
Placeholder parameters are defined using the dollar sign '$' followed by the positional index of the parameter, e.g. $0 refers to the first parameter passed to the composite, $1 the second, and so on.
For example consider the composite command SomeCommand defined as follows;
FirstCommand $0 $1
SecondCommand $1
If the SomeCommand composite is referenced in another script the parameters supplied will be substituted for the placeholder parameters in SomeCommand as shown below;
SomeCommand Hello World
SomeCommand Goodbye "Cruel World"
In the first call to the composite SomeCommand, $0 is replaced by 'Hello' and $1 is replaced by 'World'.
In the second call, $0 is replaced by 'Goodbye' and $1 by 'Cruel World'.
The Exactor distribution comes with a set of commands for scripting interations with web based and SWT client based applications, see API Docs for more details.