Feeds

A simple unit test for GUIs

Part 2: Server envy

Beginner's guide to SSL certificates

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.

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
Be real, Apple: In-app goodie grab games AREN'T FREE – EU
Cupertino stands down after Euro legal threats
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
You stupid BRICK! PCs running Avast AV can't handle Windows fixes
Fix issued, fingers pointed, forums in flames
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Bada-Bing! Mozilla flips Firefox to YAHOO! for search
Microsoft system will be the default for browser in US until 2020
Facebook, working on Facebook at Work, works on Facebook. At Work
You don't want your cat or drunk pics at the office
Soz, web devs: Google snatches its Wallet off the table
Killing off web service in 3 months... but app-happy bonkers are fine
prev story

Whitepapers

Choosing cloud Backup services
Demystify how you can address your data protection needs in your small- to medium-sized business and select the best online backup service to meet your needs.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
10 threats to successful enterprise endpoint backup
10 threats to a successful backup including issues with BYOD, slow backups and ineffective security.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
The hidden costs of self-signed SSL certificates
Exploring the true TCO for self-signed SSL certificates, including a side-by-side comparison of a self-signed architecture versus working with a third-party SSL vendor.