Swing GUI testing
2 Sep
It’s been a while since I’ve blogged, a lot has happened lately (this one’s for you Robert!). I went to meet my partner for lunch a few weeks ago and ended up having two interviews and being offered a job, which I accepted. That was one long lunch. Since then I have worked for about four weeks and holidayed for three.
What I’m doing is working for a small software firm, working on (actually, rewriting) an application specifically designed for and marketed to the fashion industry. It is a Swing application and we are running the project as Agile as we can, which is so far going very well and has buy-in at all levels.
I’ve never worked on a Swing application before and at first it felt like I was playing 
. I’m over that now… When I started we were using JFCUnit for functional testing but it has a few fundamental problems so I’m now investigating the feasability of Jemmy. It’s actually a lot easier to use and more aligned with how a user would operate the application. But I have one problem still (which isn’t specific to Jemmy): Swing’s management of windows (at least in jdk1.4.2_08).
Destroyed windows from tests are still in memory for subsequent tests, making it confusing when searching for other windows. Why, oh why?! I have read others’ complaints about this, so I’m not the only one who thinks this is broken. Of course I can get around it by making sure anything that searches for windows ignores those that are not visible but it’s a pain. Testing Swing GUIs is already hard enough with having to wait for components to load, modal dialogs and handling multiple threads.
However, I do like Jemmy and apart from its lack of documentation I’m happy with it so far, as compared to JFCUnit. And I get a kick out of watching the tests run and seeing the application work.
Hi Pam… I guess Pepijn ran into you, uh?
I haven’t done much in the way of Swing work, but I do have some concrete suggestions for you.
Ditch the “find window by name” approach. Instead, use a factory (in your production code) to create your GUI objects for you. Have the factory announce the creation of objects, and decorate or add listeners so you can intercept the closure (if needed). This lets you test directly the creation, rather than relying on a “find by name” approach – you can also use it to set up a searchable registry for tests that assume a window already exists.
(Using a factory should also assist in code re-use without having to create custom classes per panel)
I’m not sure if you’re using this for unit testing or acceptance testing. If it’s unit testing, then break your windows and panels into chunks as small as you can make them, to reduce the time to create windows, etc. Of course, then you don’t really end up seeing your application as is.
Finally, try laying an abstraction layer _above_ Swing, that is tailored for your application. Think about what would need to be done if you needed to re-implement in SWT, for example.
The abstraction layer would allow you to write higher-level tests for most of your application, while leaving the Swing-specific tests to be integration tests for the Swing implementation of the abstraction.
Anyway, glad to hear you’re enjoying yourself. Have fun.