The main idea behind Jubula's client API is to allow the execution of Test Step

s (CAPs) from within arbitrary Java code e.g. JUnit test cases (see Figure 2.1, Ide
a behind the API ). At the same time of shifting the paradigm to target a developer
audience we've tried to stick to our principles:
offer high-level test steps that are equivalent to the ones available in the
ITE: all test steps that are being executed via the API behave 1:1 the same as
the ones executed by the ITE.
an API for all toolkits: the client API is available for all toolkits suppor
ted by the ITE like JavaFX, AWT/Swing, SWT/RCP/GEF, iOS, HTML, Win and WinApps.
offer toolkit abstraction layer to keep your tests UI toolkit independent: t
he usage of the API will also allow you to specify your tests in a toolkit neutr
al way. Please note that for all of the concrete toolkit wrapper types abstracte
d super types are provided e.g. to address a javafx.scene.control.CheckBox we pr
ovide the wrapper type containing its test steps org.eclipse.jubula.toolkit.java
fx.components.CheckBox but the underlying abstracted toolkit conceptual componen
t is org.eclipse.jubula.toolkit.concrete.components.ButtonComponent .
de-couple tests and real UI widgets: you still have to create an object mapp
ing (via the ITE and export it) to keep the information that are required to det
ermine which widget to address during runtime independent from your test specifi
cation.
separation of test and AUT runtime environments: the JVM executing the tests
is a separate one (and may also e.g. run on a different machine) from the one t
he AUT gets executed in. It's communicating with the AUT VM via a TCP/IP connect
ion.
the AUT-Agent manages the lifecycle of AUTs: starting / stopping / restartin
g of AUTs is still done by instructing the AUT-Agent to do so and may also be ex
tended by the usage of autrun to launch applications externally.
Taking this as a basis, a normal execution of test steps via the client API req
uires - in general - the following steps:
Connect to an already running instance of the AUT-Agent.
Instruct it to start an AUT or retrieve a list of all currently known AUT id
entifier.
Connect to the AUT by using the AUT identifier.
Execute an arbitrary amount of CAPs (Component Action Parameter also known a
s Test steps) on this established connection to an AUT. Note: there is no result
processing implemented.
Disconnect from the AUT.
Stop the AUT.
Disconnect from the AUT-Agent.
Figure 2.2, The most important classes and their methods
iew of the toolkit neutral parts of the client API.

allows to get a general overv