InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Java GUI Testing With JRuby

Posted by Mirko Stocker on Oct 28, 2008

Sections
Development,
Architecture & Design
Topics
User Interface ,
Scripting ,
Ruby ,
Java ,
JRuby
Tags
Swing ,
Eclipse ,
SWT ,
Testing ,
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

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 eclipse.org. 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".

Marathon

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?

Swing UI Testing with FEST by Alex Ruiz Posted
JRuby by anjan bacchu Posted
Re: JRuby by Mirko Stocker Posted
Re: JRuby by J B Posted
A good alternative: Swinger and Cucumber by Demetrius Nunes Posted
Re: A good alternative: Swinger and Cucumber by Demetrius Nunes Posted
  1. Back to top

    Swing UI Testing with FEST

    by Alex Ruiz

    (Disclaimer: I'm the creator of FEST)

    A good alternative for testing Swing UIs is FEST (Apache 2.0 license.) It provides a fluent interface that makes setup and creation of GUI tests compact and readable, in plain Java. For example:


    private DialogFixture loginDialog;

    @BeforeMethod public void setUp() {
    loginDialog = new DialogFixture(new LoginDialog());
    loginDialog.show();
    }

    @Test public void shouldThrowErrorIfPasswordIsMissing() {
    loginDialog.comboBox("domain").select("Users");
    loginDialog.textBox("username").enterText("leia.organa");
    loginDialog.button("login").click();
    loginDialog.optionPane().requireErrorMessage()
    .requireMessage("Please enter your password");
    }


    Support for a Groovy-based builder (which will make the API even easier to use) is coming soon :)

    (Michael Hüttermann (Java Champion and author) will be giving the session "Agile Testing of Java Rich Clients, with Fit, FEST and TestNG" at Devoxx)

    Cheers,
    -Alex

  2. Back to top

    JRuby

    by anjan bacchu

    Having capability to use JRuby is cool. What would it take to ship a commercial tool with a GUI and JRuby ?

  3. Back to top

    Re: JRuby

    by Mirko Stocker

    What would it take to ship a commercial tool with a GUI and JRuby ?


    Shouldn't be too hard to do I guess. If you're interested in making GUIs with JRuby, you might want to take a look at this article describing several approaches or the one about deploying JRuby/Swing applications with Webstart.

  4. Back to top

    Re: JRuby

    by J B

    "What would it take to ship a commercial tool with a GUI and JRuby "

    Do you mean a product for general end users? That's what Happy Camper Studios dud with JotBot, built using the Monkeybars JRuby/Swing library.

    www.getjotbot.com

    www.infoq.com/news/2009/01/monkeybars-gui-mvc

  5. Back to top

    A good alternative: Swinger and Cucumber

    by Demetrius Nunes

    Hi folks,

    I maintain a project at GitHub called Swinger, which is basically a library of step definitions for writing Cucumber executable specifications aimed at testing Swing applications. With Swinger, you can write tests like this:


    Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    Given the dialog "About Swing!" is visible
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"


    The project home is: github.com/demetriusnunes/swinger

    There's a short video about it here: blog.demetriusnunes.com/past/2009/6/9/who_said_...

  6. Back to top

    Re: A good alternative: Swinger and Cucumber

    by Demetrius Nunes

    Oh, I forgot to mention that Swinger provides Swing automation through Netbeans' Jemmy library: jemmy.dev.java.net/

Educational Content

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.

Polyglot Persistence for Java Developers - Moving Out of the Relational Comfort Zone

Chris Richardson shows how he ported a relational database to three NoSQL data stores: Redis, Cassandra and MongoDB.

The Golden Circle – Why How What

Jean Tabaka challenges the audience to reflect on what Agile practices they are employing, how they are using them, ending with the questions “Why have their organization chosen to go Agile?