The Kaptain on … stuff

So as  as learning experience, I’ve decided to try cutting the  SwingSet demo application over to Groovy and Griffon. To make it a little more interesting, I’m going to base it off of the SwingX version.

The SwingX widgets have been a pleasure to work with in the past, and with the swingX plugin, it takes not a single line of extra code in order to use them.  The underlying SwingXBuilder provides factories which override the standard SwingBuilder syntax to replace the standard widget set with the SwingX equivalents. Simply add the prefix ‘jx’ to the standard SwingBuilder node calls and you’re in business.

Along the way I’m going to incorporate the fest and cobertura plugins to test out the UI. I’ve never used fest before but it seems that the only real requirement is to remember to give your components a uniquely identifiable id. There are additional ways of looking up components with fest, for sure, but unique ids should cover this application’s needs quite nicely. Using both together is a simple exercise on the command line.

[groovy]griffon run-fest -cobertura[/groovy]

Under the hood, Griffon uses TestNG, so the test class can also take advantage of some nice familiar annotations to assist configuration. Code coverage and testing results are provided by default in an html format, which anyone who likes their test coverage will be infinitely familiar with.  All in all, the experience of setup and execution of the testing framework is pretty painless.

The SwingSet demo is actually laid out pretty nicely for testing in the first place. There’ s a top level MainWindow class, which accepts a DemoPanel parameter. The full demo launches with a SwingXDemo subclass of DemoPanel that aggregates other subclasses of the same into a tabbed pane. Tests are free to call the MainWindow class with any of the individual panels as a parameter, so testing them on their own using fest looks like it would be a cinch.  In Griffon terms this roughly translates to a root MVC group that composes another MVC group that is specified by id. Easier to show than to explain, with an example of a call that would go in the controller:

[groovy]
createMVCGroup(mvcGroupIDParam, uid, [… param map …] )
[/groovy]

The first thing created in the SwingSet UI is the menu, so that’s what I created first as well. In the view class:

[groovy language=”true” smarttabs=”true”]
actions {
action(id: "quitAction",
name: model.QUIT_NAME,
mnemonic: "Q",
accelerator: shortcut("Q"),
closure: controller.quit)
}

menuBar {
menu(model.MENU_NAME) {
menuItem(name: model.QUIT_NAME, action:quitAction)
}
}
[/groovy]

The component names are defined in the model class so that they can easily be extracted later for testing purposes.
Including the fest plugin with Griffon adds a target which is used to create a new test, which will prompt you for a test name.
[groovy]create-fest-test[/groovy]

The new test class is created with all of the necessary code to let fest launch the base application frame. This first test is very simple, just making sure that our single menu item is present in the GUI.
[groovy language=”true” smarttabs=”true”]
@Test
void testQuitMenuItemPresent()
{
Assert.assertNotNull( window.menuItem(GriffonSwingSet3Model.QUIT_NAME) )
}
[/groovy]

That’s really all it takes to launch a new application using the test harness and verify UI component state. Man, can I think of a couple of times in the past where that might have come in handy 🙂

Next, step is cutting over the first SwingSet DemoPanel, a demonstration of JXBusyLabel – 635 lines of the usual Swing inner classes and boilerplate GridBagLayout constraints code. Really looking forward to seeing how it looks in Groovy.