Tests

Test instances are the basic building blocks of unit testing. The core interface is defined by the interface class Test.
This interface is specialised and party implemented by the TestCase class. This class serves as base class for all kinds of test cases. It could be subclassed directly or by using one of the template classes for generating unit tests.
The TestCaseAdapter templates turns simple functions into unit tests. Up to three functions could be used to generate a test case. If a function has no parameters it could be used directly. Otherwise, a Binder must must be used to fix the parameter values and adapt the function to the Functor concept. A Functor is a parameterless function.
A TestGadjet is quite similar to a TestCaseAdapter, it only uses member functions belonging to a test fixture class to create a unit test.
It is almost a special case of a TestAppliance. This template class allows also to use member functions for test set-up and tear-down. A TestGadjet relies on the fact that the fixture class defines member functions for that purposes.
A TestSuite is a collection of tests. A contained test could be a test case or another test suite.
Similar to the test case adapter, there is also a class template that uses functions to generate a test suite, the TestSuiteAdapter. Functions could be used to realize the test suite set-up and tear-down.

Exceptions

Another quite important type of object in Scrunitizer are exceptions, especially test exceptions. A TestException is a special C++ exception that is thrown when something goes wrong while executing a unit test. Two subtypes of test exceptions have to be distinguished.
First, a TestFailure is thrown whenever something goes wrong when it was expected that it could go wrong. This is the case if the outcome of some test activity is checked.
A TestError is thrown when something goes wrong unexpectedly. Test error typically occur during test set-up or tear-down, when some resource that is needed for executing the test is not available or something completely unforeseen happens during test execution.
Because it is a lot of work to wrap try-catch-blocks around all pieces of code that could generate some domain exception, CallGates could be used to handle those exception in a general fashion. A CallGate is something that is put in the invocation chain to a test activity (set-up, execution, tear-down). It serves as interface for the two templates that handle domain exceptions.
An ExceptionTrap catches an exception and turns it automatically into a TestFailure. This is handy for dealing with application domain exceptions that can be thrown by many functions to test.
An ExcptionHandler is a slight extension of the exception trap concept. When an exception handler has caught the exception specified in the template parameter, it calls a handler function that could decide what to to. It could generate a TestFailure, a TestError or simply suppress the exception.
Whenever an exception is thrown, the TestManager, the instance that conducts the execution of all tests, generates a TestExceptionRecord. Such objects relate a TestException to the Test instance that has caused the exception. This allows to deal with tests and test exceptions even after the tests have beeb executed.

Observers

TestObservers are the type of object in Scrunitizer that does all the work related to test progress and outcome reporting. To be able to observe the execution of Test instances, an observer must be registered with the TestManager.
Whenever the TestManager makes some substantial progress or has created a TestExceptionRecord, all observers are notified. So they can use all the informations offered via the TestSession interface to do their job. Four different type of test observer come with Scrunitizer.
The BriefSessionLog generates some minimalistic output that only shows the progress in test execution. A VerboseSessionLog shows every test with its name and report the outcome as soon as the test was finished. Both could be combined with a SessionReport. This lists all generated exceptions and gives a summary of the test session after all tests have been executed. Finally, the ExecutionTracer could be used in cases where one unit test crashes the test driver. It logs every single step in test executions immediately, so with the help of its output it should be possible to localise the test that damages the test driver executable.