Functional test automation for Eclipse applications with Jubula

A GUI tester that does drag&drop! At least they claim it does. This was a tutorial session where they gave us a copy of their RCP application based on Eclipse 3.6.1 and walked us through creating and running a test case. No code involved - everything is based on a hierarchical set of semantic "modules" that you assemble and set some properties on then run. Many modules are included or you can create your own. An example is a button click. The module can take input, in this case the text on the button, as a parameter provided at runtime. All the parameters for all the modules for a test suite can be provided from a flat file - good separation of test data from test "code". You can write the test suite without the app under test though I guess you'd need at least descriptions or screenshots to know what to test. Creating a test doesn't involve code though selecting and arranging modules and setting their properties is not exactly word processing but a tester should have no problem.

It's based on GUIDancer, a commercial product, that they've open-sourced and are now developing as an Eclipse project. The free version lacks the code coverage reporting that the commercial version provides. But what's free is really impressive. SWTBot API is not intuitive. WindowTester produces buggy tests and is not open-source. Neither one does drag&drop. I want to try this.

I was wondering about running tests during build and poked around http://www.eclipse.org/jubula/ and found this:

Is it possible to run GUIdancer / Jubula in a continuous integration process?

Yes, we have a command line client which allows this. The use of this client is described in the user manual.

You can also run tests on the AUT using a virtual frame buffer if you want the testing to take place independently of the actual GUI environment.

---

Is it possible to run GUIdancer / Jubula with Ant?

There is no direct ant target for executing GUIdancer or Jubula. However, the exec command can easily be used, for example:

< exec executable="GUIdancerCMD.exe" vmlauncher="false" failonerror="false" resultproperty="testResult" />

---

Can you recommend any best practices for integrating GUIdancer / Jubula into the build environment?

We recommend using a tool or framework for continuous build integration. This tool can then execute tests and evaluate the results.

We use Hudson as our continuous build integration framework. Hudson runs on a dedicated test computer, which has a stable environment and configuration. Our tests are run from this machine, with AUT agents running both locally and on other remote test machines. Hudson:

checks out the source files from the repository,
builds the application,
starts the tests, and
reports the test results.

The most basic smoke tests are run after commits throughout the day, more complex tests are executed every night, and tests with very long execution times are executed over the weekend. In this way, defects can be identified within a short time after they are committed to the repository.

---

What ports does GUIdancer / Jubula require for testing?

We require various ports to communicate in two directions:

From the client to the AUT agent: this port is defined in the preferences.
From the AUT to the client: this port is dynamically chosen, and cannot currently be defined. Therefore, any ports available on your test machine must also be open on the machine from which the test is being run.

If opening all ports in this way is not an option, we recommend using the command line client on the test machine to run the tests, so that all communication is done locally.

Looks promising to me!