Original URL: https://www.theregister.com/2007/11/12/unit_testing_2/
A simple unit test for GUIs
Part 2: Server envy
Posted in Channel, 12th November 2007 10:02 GMT
Hands on Last time I described why GUI code is difficult to unit test, and why it's generally better to avoid doing so. But that doesn't mean GUI-related code shouldn't be tested - you just need to separate out the logic.
Easier said than done? The number of times I've spoken to Java GUI coders who've said: "Swing code can't be unit-tested, so we don't bother." Then they stare wistfully across the room at the server-side developers, whose code is well covered by tests.
So, how do you write unit tests for GUI applications? I'm not claiming that the approach described here is new, but it's simple, and I've found it to be highly effective as it promotes separation of concerns, putting the behaviour where the data is, and other good OO stuff.
First, let's assume you're creating a Swing-based Customer Details panel. So you'll want a CustomerDetailsPanel class that contains the GUI code: components, layout, and Swing event handlers. Next, create a Controller class, CustomerDetailsController, which will contain the business and application logic, and contain references to the entity objects (Beans, POJOs). Any time the GUI needs to check or update something related to the data, it makes a call to its Controller to do it.
The Panel and its Controller are tightly symbiotic: the Panel must know about the Controller in order to delegate to it, and the Controller must know about the Panel to tell it to update the GUI. Design puritans might start hyperventilating at this tightly coupled two-way relationship, but in practice it isn't a problem.
However, it could become a problem when you decide to write some unit tests for the Controller - which of course is the whole point of this exercise. If the Controller contains method calls to the Panel, then you'll also need to create an instance of the Panel in your unit test - something we're actively trying to avoid doing.
The easy solution is to define a UI interface (CustomerDetailsUI), implemented by the Panel and passed into the Controller on creation, which defines all the methods the Controller will want to call on the Panel. Then in your unit test, you can simply define a mostly-empty implementation of the UI interface and pass that into the Controller instance created for testing.
In the example I'm calling this a mock UI, although the Mock Object Correctness Police will doubtless rap my knuckles as it's really a stub implementation, not a mock.
So here's what you end up with: one Panel class, one Controller class, one UI interface, and at least one Test class that contains its own minimal implementation of the UI interface as an inner class. The diagram, courtesy of the rather nice, Linux-based Umbrello UML Modeller, shows how it all fits together.
Each Panel class has one Controller class and one UI interface, at runtime each Panel instance has one Controller instance, and the Controller itself is where the data lives - the instance of a Customer bean.
I've assembled some example Swing code here. In the example, the Customer ID is validated if you press Enter or try to close the JFrame; it'll refuse to close if the ID isn't between one and 10 characters. Remember, this is just an example and you’ll be better served by something like JGoodies Validation Framework for "real" form validation.
And that's really all there is to it. No great mystery. Swing GUIs are not difficult to unit test! Sure, you could spend time grappling with GUI testing frameworks that provide questionable extensions to JUnit, but really - seriously - there's no need, as long as you keep a constant focus on good design principles.
As an added bonus, this approach also provides a roadmap towards distributing your objects. The separate controller classes could be "remoted" - turned into web services, for example. What you're then doing is creating a distributed service, which is much more useful than individual distributed objects.
Of course, separating the application/business logic from the GUI code doesn't automatically make a system "remotable". Issues of latency, security and caching will remain to be contended with, but it is a step in the right direction, as it opens up an approach that previously - with logic tightly wound into the GUI code - just wouldn't have been available. ®
Agile Iconoclast Matt Stephens has co-authored Use Case Driven Object Modeling with UML: Theory and Practice, which explores ways to drive functional tests and unit tests from use cases.