White Box Testing
Test your code
   Home      TestPattern-PresentationLayerPatterns
Author -  Marc Clifton
Marc is the creator of two open source projets, MyXaml, a declarative (XML) instantiation engine and the Advanced Unit Testing framework, and Interacx, a commercial n-tier RAD application suite.  Visit his website, www.marcclifton.com, where you will find many of his articles and his blog.
Marc lives in Philmont, NY.

Presentation Layer Patterns

One of the most challenging aspects of unit testing is verifying that information is getting to the user right at the presentation layer itself and that the internal workings of the application are correctly setting presentation layer state.  Often, presentation layers are entangled with business objects, data objects, and control logic.  If you're planning on unit testing the presentation layer, you have to realize that a clean separation of concerns is mandatory.  Part of the solution involves developing an appropriate Model-View-Controller (MVC) architecture.  The MVC architecture provides a means to develop good design practices when working with the presentation layer.  However, it is easily abused.  A certain amount of discipline is required to ensure that you are, in fact, implementing the MVC architecture correctly, rather than just in word alone.

Sun Microsystems has a webpage which I consider is the gospel for the MVC archicture: http://java.sun.com/blueprints/patterns/MVC-detailed.html.  To summarize the MVC pattern here:

It is vital that events are used for model notification changes and user gestures, such as clicking on a button.  If you don't use events, the model breaks because you can't easily exchange the view to adjust the presentation to the particular presentation layer requirement.  Furthermore, without events, objects become entangled.  Also, events, such as managed by an event pool, allow for instrumentation and ease debugging.  The only exception to this model that I have found in practice is that on occasion, a state change in the model might be captured by an event in the controller rather than the view.  Some model changes, such as user authorization, are view-less but end up affecting other aspects of the controller.

The View-State Test Pattern

This test verifies that for a change in the model state, the view changes state appropriately.

This test exercises only half of the MVC pattern--the model event notifications to the view, and the view management of those events in terms of affects on the presentation layer content and state.  The controller is not a factor in this test pattern.

The Model-State Test Pattern

Once we have verified application's performance with the View-State Pattern, we can progress to a more complicated one.  In this pattern, the unit test simulates user gestures by setting state and content directly in the presentation layer, and if necessary, invoking a state change event such as "KeyUp", "Click", etc.

As diagrammed above, the unit test verifies that the model state has changed appropriately and that the expected events fired.  In addition, the view's events can be hooked and verified to fire correctly for the simulated user gesture.  This test may require some setup on the model itself, and treats the controller as a black box, however model state can be inspected to determine whether the controller is managing the model state appropriately.