Testing the User Interface Using FIT

The problem with manual testing.

The basic problem with manual testing is that it's time consuming and not repeatable on demand. Consequently, it's best that we restrict manual testing to those places where human judgement provides a benefit; in other words, usability and look and feel issues.

The standard way of handling this issue is the four layer architecture. Counting from the outside in, layer 1 is the GUI, layer 2 is the task oriented controller, layer 3 is the actual application and layer 4 is the persistance mechanism.

This is sometimes incorrectly refered to as the MVC, or Model, View, Controller architecture, with layer 1 being the view, layer 2 being the controller and layer 3 being the model. Richard Pawson's Ph.D. thesis debunks this view, including extensive quotes from the actual originator of the MVC architecture about what he intended it to be. The thesis is online at www.nakedobjects.org. I recommend it highly, although it is not light reading. The MVC architecture implemented in Smalltalk-80 is a pale imitation of what was intended, and the common explanation of that architecture are so far off the mark that they are positively baroque.

Testing at the task oriented interface level

The essential idea behind this is that you can remove all of the application logic from the GUI layer and then replace it by the FIT fixtures required by ActionFixture or DoFixture. Shoving the application logic down into layer two is beneficial in two ways. The first is that it simplifies writing the FIT fixtures; the second is that it makes the GUI transparent to application logic.

In any case, attention to the XP simple design principle of relentlessly removing duplication will shove the application logic into layer two as soon as you start FIT testing.

FIT tests designed in this way closely model the typical interactions a user would have in a task oriented interface.

Testing at the Domain Model level

Testing at level 3 (the domain model) seems to lead to a great deal of confusion both about how one would do it, and whether it actually has any utility as a customer or acceptance testing techinque. It is not, after all, the actual user visible interface, nor is it isomorphic to it.

It is possible to do, and to do quite productively. The key is that the upper part of the domain layer has to be "behaviorally complete" domain objects. If it consists of a hodge-podge of objects that are crafted on techincal grounds, then there is indeed no point to FIT testing.

The best information on this is the Naked Object model, at www.nakedobjects.org. Unfortunately, the software is Java and DotNet rather than Python, but writing a FIT fixture to handle the same implementation protocol would be relatively simple.