In my job, we build a lot of desktop applications. They used to be written mostly in C++ for sake of performance a long time ago, but we’ve migrated all apps to Java, since Swing got to a reasonable level of performance these days.

Since I’ve got there in 2005, I’ve been preaching loudly about the benefits of test-driven development and managed to get quite a lot of people infected with the test-first bug.

However, we’ve got a lot of legacy code. I mean A LOT, really. That kind of code that was never meant to be tested in isolation, and unfortunately, will never be.

That doesn’t mean we can’t make use of automated testing. We just have to go up all the way up to the UI to be able to do it. I know, it’s slow and brittle but it’s much better than nothing.

I’ve been working a lot with Cucumber and investigating it deeply to see if that could be the missing piece we needed to make testers and developers really work together, so we could free ourselves from the manual testing hell.

Cucumber also makes UI testing a lot less brittle and easier to maintain since we can change the UI and keep the tests we already got, having only to fix the step definitions mostly.

That’s why I started writing Swinger. Swinger is a collection of step definitions that you can use to automate testing in Java/Swing applications. It makes use of the Jemmy library to find and manipulate Swing widgets.

It’s still very experimental and it has a long way to go before I can release it as a gem, but so far I’ve been able to write some interesting and mildly complex test cases with it.

I’m using the SwingSet demo application that comes with the JDK as my test bed and it’s quite fun to watch Cucumber drive it crazy in a matter of seconds. Wanna take a look? Check it out:

Continue reading »