The main idea behind Jubula's client API is to allow the execution of Test Steps (CAPs) from within arbitrary Java code e.g. JUnit test cases (see Figure 2.1, “Idea 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 supported by the ITE like JavaFX, AWT/Swing, SWT/RCP/GEF, HTML.
offer toolkit abstraction layer to keep your tests UI toolkit independent: the usage of the API will also allow you to specify your tests in a toolkit neutral way. Please note that for all of the concrete toolkit wrapper types abstracted super types are provided e.g. to address a javafx.scene.control.CheckBox we provide the wrapper type containing its test steps org.eclipse.jubula.toolkit.javafx.components.CheckBox but the underlying abstracted toolkit conceptual component is org.eclipse.jubula.toolkit.concrete.components.ButtonComponent .
de-couple tests and real UI widgets: you still have to create an object mapping (via the ITE and export it) to keep the information that are required to determine which widget to address during runtime independent from your test specification.
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 the AUT gets executed in. It's communicating with the AUT VM via a TCP/IP connection.
the AUT-Agent manages the lifecycle of AUTs: starting / stopping / restarting of AUTs is still done by instructing the AUT-Agent to do so and may also be extended by the usage of autrun to launch applications externally.