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.
News
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
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?
RelatedVendorContent
Five Key Practices to Agile ALM
A Guide to Branching and Merging Patterns
Agility at scale, become as agile as you can be
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
-
(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 -
Having capability to use JRuby is cool. What would it take to ship a commercial tool with a GUI and JRuby ?
-
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. -
"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 -
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_... -
Oh, I forgot to mention that Swinger provides Swing automation through Netbeans' Jemmy library: jemmy.dev.java.net/
6 comments
Watch Thread Reply