Parent Previous Next

How much UI code, concerned with Swing or AWT, did you write so far? None!

So guess what you need to test your application!

Nothing but ordinary JUnit or whatever test framework you prefer. You don't need any tricky and mostly expensive toolkits for automated Swing UI testing like Squish® or Window Tester or Test Complete®. Even if you can afford the tools - many UI tests tend to be hard to write and even harder to maintain. Especially over serious refactorings.

So have a look at this test which can be found in directory examples-firststeps/quickstart/navigate. It is a pure JUnit 4 POJO test for the RegisterNewCar class and - as there is no other code around - also for the car registration UI.

public class RegisterNewCarTest {

   static final String TEST_LICENSE_NUMBER = "PB-LH 345";

   RegisterNewCar carRegistration;


   public void before() {

       carRegistration = new RegisterNewCar();




   public void testSuccessfulRegistration() throws Exception {






   public void testExceptionByNonuniqueLicenseNumber() throws Exception {






   // Rest omitted


The convenience method populateCarWithMinimalUserInput() simulates user input in the registration mask simply by calling setter functions. The UI would not allow to go on working with invalid user input, so it is usually a good idea to add appropriate validity checks for the test input. Otherwise the unit tests may work on unrealistic data which could never be typed in interactively. Most input constraints are usually defined by annotations of the Bean Validation standard (see chapter Constraints and validation) which can easily be checked programmatically. In the car registration test it looks like that:

   private void populateCarWithMinimalUserInput() {

       Car newCar = carRegistration.getNewCar();



       Validator validator = Validation.buildDefaultValidatorFactory().getValidator();

       assertEquals(0, validator.validate(newCar).size());


Testing Layouts

To be absolutely honest you actually did some UI programming already although it was not Java coding. In chapter Layouting you have already learned to manipulate the generated layout files and this is something which needs testing too. Therefore gengui provides the class gengui.util.jfdtester.JFDTester which allows to automatically check the general consistency of layout files with the domain classes they represent. The JFD tester finds out if

The class may be run from within a unit test and it is recommended to add such a test to the project's test suite. The need for such a test is generally a good sign. As soon as you work with the Naked Objects approach you will experience a change in the developers' behavior. They will more and more concentrate on the domain classes' logic without even starting the UI for every little test. They rather rely on their unit tests, simply because it is much faster and cleaner. The JFD tester keeps you from nasty surprises when the fun work is over and the tedious, interactive integration test follows.

Created with the Personal Edition of HelpNDoc: Easily create Web Help sites