SyncTester is an extension of TestCase that is useful for testing objects whose method are to be called sequentially, in effect synchronizing methods with potentially asynchronous behavior.
To take advantage of this helper class, you must declare a dataset named "<instance name>_methods", with a root node whose children are the method names to be called synchronously. The method nodes must be named "call", and have at least the "name" attribute defined. If the method needs to be called with arguments, specify them as value of the optional "args" attribute (only one argument is currently supported).
Your specific tests will only run once a method returns. It is possible to provide an inspector method for each of the asynchronous methods declared; you reference it with the "tester" attribute of a node in the dataset. These inspector methods must be defined on the SyncTester object. If you dont specify a tester for a method, the default handler named
Generally speaking, you would expect that an event is sent when a method is done. This framework allows you to specify what event indicates the end of method execution by declaring the "event" attribute. It is assumed that the sender of the event is the object referenced by the
For example, if you have an instance of this class named "userinfo", then your list of methods might be declared like this:
This is the LZUnit library. LZUnit is an implementation of the
xUnit testing framework for LZX programs (cf., JUnit
A Cook's Tour).
Each of the xUnit components is implemented as an LZX tag with the
corresponding name. Tests can be written by defining a subclass of
TestCase and defining test...
methods. A test suite can be created by enclosing any number of
TestCases in a TestSuite.
The usual helper methods, assertTrue,
assertEquals, assertWithin,
assertSame, etc. are available for implementing the
tests. (See the documentation of Test for a full
list.)
An LZX program that consists of a
TestSuite will, when loaded, automatically run all of
its child TestCases and report the number of test cases
run, the number of failures, and the number of errors. If any error
occurs, an obvious error message is presented.
Below is a simple example of the use of LZUnit demonstrating a successful test, a failed test, and a test that causes an error.
For a more in depth discussion, please see the Developer's Guide.