A prolific blogger, a frequent presenter at conferences and a champion of automated Swing UI testing. Meet Alex Ruiz as the interview series on Swing, JavaFX and related topics that started with Amy Fowler, Mikael Grev, David Qiao, Chet Haase, Andres Almiray and Richard Bair continues.

Tell us a little bit about yourself

My name is Alex Ruiz. I’m a programmer. I love programming and I love Java. In a previous job, as a consultant for ThoughtWorks, I developed a healthy enthusiasm for automated testing.

I work on open source projects on my spare time. My first “serious” open source project was a library, part of Spring Modules, that performed transparent caching using Aspect-Oriented Programming techniques. I “retired” from the project a couple of years ago and as far as I know, the project is still active and under development! I’m also the creator of an open source project for functional testing of Swing UIs called FEST (Fixtures for Easy Software Testing.)

I also enjoy writing technical articles and presenting at various conferences.

I currently work at Oracle as a Software Engineer for the tools organization. I’m part of the team that develops the framework used as the foundation for JDeveloper, SQLDeveloper and many other middleware tools and products.

The readers of this blog have seen your name in connection with FEST Swing project. What is your “elevator pitch” for this project?

This is the shortest overview I could come up with :)

Testing user interfaces has been traditionally a challenging activity. In my opinion, writing tests is just the beginning. Maintaining them and troubleshooting test failures is difficult as well, if not more. FEST-Swing aims at changing that by providing the following features:

• A compact, fluent and easy-to-use API that makes creation of tests enjoyable
• Such API is also quite readable, making maintenance of tests pretty easy too
• Many features (like desktop screenshots) that can help us troubleshoot any unexpected test failure in a quick manner
• Support for verification that our user interfaces are not violating any EDT access rule

Why did you decide to focus on testing Swing-powered UIs?

I always thought that Swing was (and still is) the best UI toolkit in the market. It is cross-platform, powerful and flexible. I liked the ability to change the look and feel of applications to make them look the same regardless of the underlying platform. And on top of that, I could code UIs using my favorite language, Java.

I started by creating some very small Swing apps just for fun. Following my curiosity for testing, I found that testing UIs was a very fascinating challenge for many reasons. I realized that, to test UIs, unit testing was not as helpful as I wanted. Sure, I could test that my ActionListener performs some logic correctly, but I thought that it was not good enough. Unit testing of UI classes was as fragile as using mock objects: developers need too much knowledge of the internals of the UI. And, if the internals change without changing the actual UI behavior, tests can fail miserably. I also understood that testing UI-related classes in isolation could not give us confidence that the UI, as a whole, behaved as expected in front of the user. In order to be effective, tests needed to verify the behavior of a UI as if a user was actually using it.

I started looking into open source tools for functional tests of Swing UIs. Although all of them could simulate user input successfully by using the AWT Robot, they were not as usable as I desired. My first impression was that their APIs were too verbose, making creation and maintenance of UI tests quite tedious.

Then my wife, Yvonne, and I started doing some experiments with fluent interfaces, which ended up as FEST. From that point on, the project has grown thanks to the feedback and contribution of its users.

Should UI testing layer be part of core distribution of UI toolkits, or should this be left to interested third parties?

That’s a tough question. I have mixed feelings about this…and a long answer!

It would be ideal to have both the UI toolkit and the testing layer distributed together, to expose more developers to the benefits of UI testing. We might assume that if the UI testing layer was built in within the toolkit, more people would embrace automated testing. Unfortunately, that is unrealistic and impractical.

I think that having both the toolkit and testing layer as a single distribution actually complicates the distribution process enormously. The first reason is how these two depend on each other. The testing layer obviously depends on the UI toolkit. New features or bugs in the toolkit are very likely to affect the features to add to the testing layer. The opposite is not true though. By having the toolkit and testing layer together, it would be hard to decide when to release a new version of the product. For example, would it be fair to delay the release of the toolkit because of some unfinished features or bug fixes in the testing layer? Probably not.

It is also essential to know the needs of the toolkit consumers. I bet many of them don’t care about automated UI testing, can live without feature A or B in the testing layer, or need a critical bug fix in the UI toolkit to release their own products. Although UI testing is necessary, it is still not a popular practice. Automated testing in general is not as popular as it should be. I think the best way to serve users is by satisfying their most important needs. In this case, that would be the UI toolkit.

The opposite is true too. There are (a smaller number of) users that care about the testing layer as much (or almost as much) as the toolkit itself. They would also be negatively affected if a feature or bug fix they need in the testing layer is delayed due to the development of the toolkit. A good example is Swing. It is distributed with a bigger product, the JDK. We would have to wait for a new release of the JDK to get updates, new features and bug fixes to the UI testing layer.

I think what Sun has done with Swing is pretty good job already. The inclusion of the AWT Robot facilitates the creation of true cross-platform UI testing tools and Swing itself can be testable, with a few OS-dependent hacks.

In short, I think UI toolkits should not be distributed with a UI testing layer. These are two complex products that solve two difficult problems. It is better to focus on them separately but always having testability in mind.

Sure, third parties interested in UI testing can create the UI testing layer. Competition is a good thing. But this shouldn’t exclude the creator of the UI toolkit, as long as the creator has enough interest, knowledge and manpower to work on the testing layer.

What, in your opinion, are Swing’s pain points and what can be done to address them?

As I mentioned before, I think Swing is very powerful and flexible. That is a problem too. It is too easy to mess things up, and get away with it. The lack of documentation is, in my opinion, the major pain point. Sure, we have documentation on how to use Swing components and threading. But, in my opinion, we are lacking a guide or blueprints for different types of applications. From simple details as how to organize UI code in packages to how to divide responsibilities among all the UI-related classes. It would nice if somebody wrote a book about this topic!

Additionally, Gregg Bolinger had a fantastic idea: create a project to show developers how to use Swing correctly and effectively. I can’t wait to see the outcome!

Given full control, would you change anything in Swing core layer going forward?

1. Add support for checking violation of Swing threading rules
2. Retrofit generics to Swing. I cannot believe we still have to code like this:   MyWindow w = (MyWindow) SwingUtilities.getAncestorOfClass(MyWindow.class, textField)
3. Replace Vector with concurrent collections
4. Add MigLayout and DesignGridLayout to the JDK
5. Remove the Metal L&F once and for all
6. Better DnD support: minimize the code that users have to write
7. More UI components! Include Flamingo and JIDE in the JDK

Do you agree with Richard Bair’s assessment that JavaFX is “Swing 2.0”?

That is difficult to answer since Richard’s statement is too general. My interpretation is JavaFX can be considered Swing2 in the sense that Sun doesn’t have to worry about backwards compatibility. Other than that, I don’t think that JavaFX is really Swing2. My understanding is that JavaFX’s scope is to create and deploy “rich applications” in different platforms (desktop, web and mobile.) That’s way beyond Swing’s scope.

Given the small amount of information given by Sun, it is difficult to predict the direction of JavaFX and Swing.

Are you interested in extending the concepts of FEST Swing to other Java-based UI toolkits, such as SWT and JavaFX?

I’ve been thinking a lot about this lately. I thought about porting the ideas of FEST-Swing to SWT a few months ago, but I’m not sure if there is a need for it. There is already a project using fluent interfaces for SWT, SWTBot, which is in incubation as an Eclipse project. If this project satisfies the needs of SWT users, I think there is no reason for us to support SWT.

We are seriously considering supporting JavaFX. I tried to use FEST-Swing to test a JavaFX, without success. I think the problem is that the component hierarchy is different in JavaFX and new testing layer (or at least a new component hierarchy strategy) needs to be created. Michael Hüttermann (good friend and FEST teammate) and I will be doing research about testing JavaFX UIs starting in January 09.

Would you like to share the future plans for FEST Swing beyond the impending 1.0 release?

There is really not too much too say, since we have been focused on releasing 1.0 first :)

After FEST-Swing 1.0 (due in mid-January 09,) we will be implementing many enhancement requests from our users. We will be adding support for 3rd party UI components (Flamingo and JIDE.) Finally, we will provide a simpler API built with Groovy.

We need to sit down to prioritize all the pending tasks we currently have.

Anything else that you would like to add?

Swing is, in my opinion, the most powerful and flexible cross-platform toolkit out there. I don’t think it is going away anytime soon. There is too much investment, both from Sun and Swing users, to let it die. I agree, Sun needs to take care of Swing: fix bugs, and add new features and UI components. The APIs need to be “modernized” too. We need to get involved and help out too. We can create missing UI components, new look and feels, and write tutorials describing how to do things right with Swing! Just like you, Alex Potochkin and David Qiao, to name a few.