Comments on: Looking for TDD Swing code

By: Rob@Rojotek » Blog Archive » Utility method for TDD of a SwingBorderLayout

Thu, 12 Jun 2008 02:25:46 +0000

[…] have been working with different ideas for Test Driven Swing code for a while now. Recently, Suneth and I came up with a new strategy for testing Swing BorderLayouts (unfortunately […]

By: George Dinwiddie

George Dinwiddie — Tue, 30 Nov 1999 00:00:00 +0000

Jeff Waltzer and I started a small project to try out TDD GUI. We started with straight junit, and found the code was driving us toward reimplementing jfcunit, so we switched to that.

We didn’t finish the project, but the experiment was a success. See http://sourceforge.net/projects/mp3tagmaster/ for the code.

- George

By: Ian Bourke

Ian Bourke — Tue, 30 Nov 1999 00:00:00 +0000

I don’t actually have any code to give you, but I have written a Swing app in a test-driven manner (well, as test-driven as I could make it at the time).

Basically, provided that you have a proper MVC design, you can mock one or two of the three pieces and test the third in isolation. However, unless you use a clever “I can mock a class” mock library, this does mean that you end up having a bunch of interfaces for your MVC classes.

For the app that I worked on, we actually had a common interface for each view and controller that could be mocked, that provided pub-sub methods for gui “events”. That meant that we could mock the controller and check that the view published the correct messages when we fiddled with the Swing components, and the mock view received the right messages when we called methods on the controller. If I remember correctly, we never needed to mock the model, as it was essentially just a value object.

It might be more flexible to mock the classes directly, so that you aren’t constrained by the potentially limited messages based notification through the limited methods on the interfaces described above.

Of course, this still leaves all of the layout to do with no tests at all

By: Stuart

Stuart — Tue, 30 Nov 1999 00:00:00 +0000

I’ve also done something similar to what Ian describes above. I’ve built my form using a factory and then mocked that, I’ve also bound the properties of the components through to an XWork action, using a binder class that can be mocked too.

That way the only things that are left out are the layout and the listeners on the components. Buttons are easy as you can call a doClick directly, but TreeControls / Tables etc are a pain. You have to get a handle on the listener and invoke it directly with an Event.
Check out http://sourceforge.net/projects/pendulum/ from the CVS repository and give it a whirl.

By: No two

No two — Tue, 30 Nov 1999 00:00:00 +0000

Good luck!

By: Ollie

Ollie — Tue, 30 Nov 1999 00:00:00 +0000

There’s a realy good book on TDD which covers Swing tests in some detail. “Test Driven Development: A Practical Guide” by David Astels. From memory if focusus on the NetBeans “Jemmy” test framework.

By: Stuart

Stuart — Tue, 30 Nov 1999 00:00:00 +0000

I see this “Test Driven Development : A practical guide” being pointed out everywhere on these sort of threads, and I bought it… more fool me! Although it introduces you to the EasyMock framework, the tests behind the GUI are exceptionally long and drawn out. They’re fine for small apps, but for anything serious good luck in writing those tests!

By: David Hall

David Hall — Tue, 30 Nov 1999 00:00:00 +0000

As part of my JGA library, I’ve developed a small set of swing models, renderers, and editors for which I’ve created junit tests using jfcunit. It’s an lgpl project, and the cvs tree is browsable from my homepage. It’s not a lot of code, but there’s one datapoint you can work with.

http://jga.sf.net/