The
architecture emerged in conjunction with early class modeling. Please examine
the rather simple model.
This uses the exquisite Layer Pattern. The basic rule is a layer can call down but not up. The Tester partition has the root Test and manipulates the tree of tests using the root Test as the entry point. The GUI tells the Tester to run a suite of tests. These three partitions are very independent and can be freely substituted due to the loose coupling designed in, using Java interfaces as plugpoints.
However layers do need to do the equivalent of calling upward. This must be done using super loose coupling. Otherwise an upper layer is too tightly bound to a lower to layer to swap out the upper layer.
To call upward, the Test Cases partition throws exceptions when problems occur, such as AssertionFailureException. These are caught by the Tester, results are recorded, and the suite of tests continues running.
To call upward, the Tester partition emits events when the state it wants to publish changes. These events are received by the GUI layer and instantly show up on the visual tool. For example if an assertion failure occurred it would be added to the list of failures and the Failure Count would be incremented.
Not shown on the diagram is the key plugpoint - the Test interface in the Test Cases partition. This is what the entire design revolves around. The tests you write must all implement Test. To make this easier a default implementation (TestCase) is provided that you can subclass easily.
The conceptual integrity of Jester consists of the invisible claylike molding the three layers and Test give to any developer using the product. Generally one is never aware of much more than TestCase and a few helpers. The rest of Jester lies outside your "field of confusion", simplifying, satisficing and helping you along in a lightweight, transparent manner.