Recording Tests

A test is a series of actions with an expected result or results. It is an example of the correct behaviour of the system. Tests may be written by hand using the external functions of projects.

Another way to create a test is to record it. Recording a tests consists of performing a series of actions through the GUI, or messaging interfaces. The external calls made by these actions are logged to the test log. The resulting series of calls may then be saved as a test.

Support for Recording a Test
In creating a test we want to identify the expected behaviour of a system. The world outside the system makes calls to the system.

From the developers point of view the system being tested is one or more projects. The world outside the system consists of,
 * Other projects
 * Messages from other systems.
 * Messages from the GUI.
 * Data retrieved from the database.

If we have projects which provide a thin wrapper between the messaging system and our projects, then we can simplify the model. The internal system (the system we are writing tests for) is a set of projects that the developer defines. The external system is the other projects.

There are two types of calls that we need to record,
 * External system calling an external method in the internal system.
 * Internal system calling an external method on the external system.

Each of these calls needs to be captured as a constraint on the system. We may also the direction of calculation (what data was given to the call and what data was calculated by the call).

In capturing a calls as constraints the values of objects need to be captured. For simple objects this is performed by asking the object to serialize its value. E.g. the values for,


 * Integer
 * Real
 * String
 * Boolean

may be captured for recording in a test.

For complex objects that refer to other objects, it may not be practical to serialize the whole object. In any case only the values that are actually used in the test are relevant.

In this case a variable needs to be constructed for each unique object. A mapping links up the object to the variable so that when we are referring again to the same object, the constraint uses the same variable.

Calls from the input system to the external system represent constraints on the objects from outside the project. Some of these constraints may be regarded as data setup for the test, and others represent interaction between the two systems.

The full set of constraints represents forms the basis of a test. We may then want to focus the test down onto a particular result. This may be achieved using Explanation.

Capturing Calls as Constraints
???? This section needs work ????

I would like to regard functions are regarded as being a special kind of class. In particular a function may inherit its behaviour. A function is a class with functions,


 * Call function
 * Run function

All functions inherit from the class Function. Functions that have the "external" scope inherit from FunctionExternal.

FunctionExternal implements the call method as,

CallText is the text representing the call to the function. This is the text that will be added to the regression test.

GetRegTestLookup identifies a particular object. Some objects may be represented explicitly by there value; e.g. int, boolean, String. Others are represented by a code that identifies them.

The base implementation of GetRegTestLookup is in the Object class.