General Assumptions

The TOSTER is a system for sharing a set of tools that allow to implement methods of object-oriented testing. Any method based on UML diagrams and on the software source code can easily be implemented as a TOSTER module. The environment itself makes a number of mechanisms available, such as information transfer from UML diagrams, mapping this information to source code, introducing modifications to the source code, launching the tested application or presenting the results. The TOSTER environment makes use of the DFT (design for testability) concept by providing a mechanism for transferring certain method-peculiar information from the CASE model.

2)   The Testing Process

TOSTER allows the use of the so-called "black box" testing scheme. The basic testing unit is a class, uniquely defined by a set of messages it has access to, and a set of its attributes. The testing process has the following stages:

a)      preparation of the testing scheme: import of information from the CASE model and import of source files; presenting the content of the files as diagrams and vice versa (both automatically and "manually")

b)      interactive introduction of additional information typical for the particular method of testing: TOSTER offers a graphical interface that makes the entering of such information possible. Apart from that, the information can be derived from the CASE (DFT) model.

c)       preparation of source files for compilation : TOSTER provides a mechanism for modifying the C++ and Java source code; it also defines an interface for introducing such modifications in source files written in other programming languages.

d)      compilation of the tested program

e)      presentation of the results of the test

3)   Implementation of the Environment

The TOSTER environment was implemented in Java as an application with a user interface based on the SWING library. Information is transferred from the CASE model by means of an XML file whose structure was based on the XMI (XML Metamodel Interchange Format) standard. The file is generated by a script written for the Paradigm PLUS system. Testing methods are attached to the system as Java classes, which basically are specializations of the TestMethod class.

4)   Testing Methods

Currently there are two object-oriented software testing methods under preparation:

a)    sequence specification

The method was put forth by Shekar Kirami and W. T. Tsai and published in Object-Oriented Programming Oct. pp 28-38. An object has its specific state and provides a certain set of methods. Method, in turn, modify the values of attributes which define the state of the object. Therefore, the execution of a method as a response to a message {/event?} influences the state. As a consequence, the state of the object depends upon the set of messages it received. The result of the method depends on the methods so far executed. {.. and ..}  Thus the correctness depends on the order of the executed methods. It is the specification of their sequence that is a condition for the correctness of calls of methods of the given class.

The method implemented in the TOSTER environment reads the correct sequence of methods for each of the tested classes from the diagram of states. Next, it checks whether the methods executed on the object form the

b)     state vector method

This method was introduced by C.D. Turner and D.J. Robson in their article "The State-based Testing of Object-Oriented Programs" ("Proc. IEEE Conf. Software Maintenance" 1993). The method bases on  a valuable  remark that the state of an object of a given class can be specified by specific values of a certain subset of its attributes. In a state diagram that describes a given class, it is possible to assign a set of attribute values to each of the states the diagram includes, such that will make it possible to declare that the object is currently in that particular state. This allows to unambiguously describe any state by a unique vector of attribute values. The values of the attributes can be detailed (a specific value) or general (ranges of values or set of detailed values).

The above method was applied in the TOSTER environment by describing the state vectors by means of specific values of attributes. Next, the source code of the program is modified in such a way that the current state of the object is determined  before and after each execution of an object's method (on the basis of the values of attributes). This makes it possible to check the sequence (order) of method calls and the correctness of state transition .