Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Java GUI Testing With JRuby

Java GUI Testing With JRuby

GUI testing is much more time-consuming and difficult than unit testing and thus often neglected, even in generally test-driven development teams. We take a look at two possible solutions to create GUI tests for SWT and Swing applications that promise to make this task easier.

Why are GUI tests harder to write? GUIs generally need more setup than simply instancing a class, and because the interaction is often asynchronous and often involves a mouse, it is harder to simulate a user's behavior. One approach to GUI testing is to provide an interaction recorder that monitors the tester and creates a script that can then be later replied. There are several problems with this approach: Depending on the recording format, it can be quite hard to change the test after changes in the UI occured; and naturally, test-first development isn't feasible.

The other option is to create the tests programmatically. Here it mostly depends on the framework how comfortable writing tests is. A simple and efficient way to identify UI-elements and facilities to wait for asynchronous operations to finish are crucial.

SWTBot and Marathon are both applications to write GUI tests for Java applications. SWTBot uses Java and is thus potentially usable with JRuby. Marathon even uses JRuby (or alternatively Jython) directly to script the tests.


SWTBot is a testing tool for SWT and Eclipse based applications, and provides an API that simplifies the access to SWT and Eclipse components. The tests can also be run via an Ant task, so you can integrate them with your continuous integration builds. SWTBot is licensed under the Apache 2 license.

InfoQ spoke to Ketan Padegaonkar, SWTBot's developer. Ketan works for ThoughtWorks, so we wondered if there's anything happening with regards to JRuby and DSLs:

This is definitely on the list of things to do for SWTBot. There's just a lot of API that SWTBot is still lacking, and we're working on moving ahead with what we have. Most of SWTBot is built based on the requirements and feedback from the team developing Twist and the SWTBot community. There's been no real demand for JRuby integration so far. I believe this is because there's not too many people programming SWT/Eclipse using JRuby. So JRuby integration has taken a back seat, for now.
SWTBot 2.0 (in beta as of now) is providing a combination of FluentInterface and a really tiny DSL to search widgets. I think this is a good way to move ahead and provides for just about enough syntactic sugar without going the complete JRuby way.

SWTBot also provides a recorder, what's its current state?

The recorder was developed as a proof of concept, and has not been touched much. It lacks support for a lot of controls, and does not record all operations, although it is quite trivial to add support for these. The recorder records code in an intermediate format, similar to an Abstract Syntax Tree. This representation can then be output in a language of your choice, currently it supports Java, but even Ruby is possible.
On another note: Record and playback is not the recommended way to write tests (see TestingGUIApplications and Recording vs. Coding). Primarily because the complete script for a workflow (or all the scripts) need to be recorded again for tiny changes. SWTBot recommends using the PageObject/ScreenObject pattern (or see reusing functional tests).

So what are the plans for the future?

SWTBot has been a learning experience in a lot of ways for everyone involved. SWTBot in its current state is the third rewrite. We made quite a few mistakes in 1.x that have been fixed in 2.0.
We've also moved the Java 1.4 codebase to use the new features that are available with Java 1.5, especially generics. We've also decoupled a few subsystems within SWTBot. This would make SWTBot a lot more extensible in order to support multi page editors, Eclipse rich form editors, and GEF.
There's also a proposal to move SWTBot to This would enable SWTBot to be accessible to more users, and would benefit everyone.

Some good tips and tricks on testing with SWTBot can also be found in David Green's blog on "Eclipse GUI Testing Is Viable With SWTBot".


Contrary to SWTBot, Marathon can be used to test Swing applications. Marathon comes with its own editor and test runner, it also supports debugging and provides Ant tasks. Marathon is developed by Jalian Systems in Bangalore and licensed under GNU LGPL. We talked to Dakshinamurthy Karra, Marathon's maintainer and main developer.

There exist much more tools to test Swing applications than SWT, so we asked whether there are plans to add support for SWT:

We have plans for releasing a commercial version based on Eclipse. It is delayed due to various reasons. We expect the release to happen in next few months. Our immediate concentration as a team will be on adding Web testing support to Marathon. Depending on the demand, we are open to add support for SWT. Till now we received more requests for Web application support than SWT.

Marathon supports JRuby and Jython, what were the reasons to choose these two languages?

Jython was the language of choice of original developers. We (I) personally like Ruby and hence JRuby support is added. Marathon architecture supports pluggable scripting models. Any language that is supported by JVM (Groovy, Bean shell, Clojure) can be added to it.
Another reason for preferring Ruby is the ability to create DSLs. There were some plans (still nascent) for adding keyword based testing to Marathon.
That said, we will be happy to accept contributions from the community for other language support.

Looking at the screenshots of Marathon, the interface looks similar to Eclipse, is there a relation?

We will be releasing a commercial version (tentatively named MarathonITE - Marathon Integrated Test Environment) based on eclipse platform. Eclipse is our development platform of choice and that is one reason the UI looks similar to eclipse. When we need to find the right way to implement a feature - we usually check how eclipse implements the same.
There are no plans for integrating Marathon (OSS version) into an IDE.

Using JRuby (of Jython) for testing can also be a good opportunity to sneak a dynamic language into a more conservative development environment.

How do you create UI tests?

Rate this Article