Build Test Software

We build test cases for various aspects of testing such as functional, structural and interaction for the various classes into a separate test hierarchy. We group these test class hierarchies into a test architecture. This architecture is called Parallel architecture for component Testing (PACT) for building test cases, and PACT architecture parallels the architecture of production classes (McGregor).

PACT uses abstract classes to specify the functionality that must be included in each class. It provides some of the services required by each test class. The abstract methods of parent test classes are inherited by the test heirs. A generic test harness class specification with abstract functional, structural, and interaction suite definitions provide guidelines to the tester that s/he must use this standard and provide concrete test class with implementation methods.

Design of the test software

• Build test classes that correspond to the class under test.
• The test object creates instances of CUT, send messages to it that are the tests.
• The test class provides the test case, test script, and test suite methods
• Functional suite - tests that are constructed to cover the specification of the class.
• Each test suite method is a concrete implementation of methods specified in GenericTestHarness.
• Each test suite method invokes a series of script methods.
• Each test script creates an OUT from the CUT using one of the constructors.
• The script then invokes the test case(s) specified in its code, and a script method controls one or more test cases.
• A script may (re)appear in more than one test suite provided it is a valid test case for both types of test suites.
• Each test class encodes the correct response, so the test object can validate the output from OUT.
• The test case returns the result to the script.
• For test script with multiple test cases, the results of all of the tests are combined to determine the final result.
• Written tests can be reused.

Demonstration: Message sequence diagram illustrating the test algorithm for human player

Demonstration: Message sequence diagram illustrating the test algorithm for Game

• Remember Interfaces do not have any implementation methods, and abstract classes do not have complete implementation.
• All classes including interfaces and abstract classes have pre/post conditions as part of the specification
• Use guided inspection of an interface to examine the completeness of the specification by considering the role described by the interface.
• Pre & postconditions should be checked for consistency.
• Check if preconditions of any methods contradict.
• Are the parameter types and return typescorrect models for the behaviour given in the interface?
• Functional test suite created from the assertion description above.
• For methods with implementations in an abstract class, create structural test suite as well.
• As a class is developed, functional test suite is done first as it can be built as soon as interface spec. is known
• Structural and Interaction test suites are added when internal structures are known.