|
The Power in your Hands |
The Pt::Unit module provides a complete framework for effective unit testing. Simple tests are implemented by deriving from TestCase, multi-method suites by deriving from TestSuite. Setup and teardown of resources is provided by the TestFixture interface. Test conditions are verified through the Assertion class and the PT_UNIT_ASSERT macros. Execution order and data-driven repetition are controlled by a TestProtocol. Tests are auto-registered with RegisterTest and run by the Application class, which reports results through Reporter. A ready-made main() function is available by including TestMain.h.
Simple Test Cases
A TestCase can be used for simple tests that require a initialization and deinitialization of resources. The implementor is supposed to implement the abstract method 'test' and the methods 'setUp' and 'tearDown' for resource management. When the test is run, 'setUp' will be called first, then 'test' and finally 'tearDown'.
Once the test is written it can be registered to an application by using the RegisterTest class template.
Test Suites
The TestSuite is used to implement protocol and data driven tests. It inherits its ability to register methods and properties from Reflectable. The implementor is supposed to write and register the required test methods on construction.
Once the test is written it can be registered to an application by using the RegisterTest class template. Include TestMain.h in exactly one source file to provide a main() function.
The default protocol will run each registered test method when the test is run. Before each test method setUp() is called and tearDown() after each test. The TestProtocol can be replaced with a customised one and reflection can be used to call any method multiple times with the required data.
Assertion Macros
Assertions are modeled as an exception type, which is thrown by Unit tests when an assertion has failed. This class implements std::exception and overrides std::exception::what() to return an error message Besides the error message, Assertions can provide information where the exception was raised in the source code through a SourceInfo object. It is recommended to use the PT_UNIT_ASSERT for easy creation from a source info object.
The following assertion macros are available:
- PT_UNIT_ASSERT(cond) — asserts that the condition is true.
- PT_UNIT_ASSERT_MSG(cond, msg) — asserts with a custom message.
- PT_UNIT_ASSERT_EQUAL(a, b) — asserts that a == b, printing both values on failure.
- PT_UNIT_ASSERT_NEAR(a, b) — asserts that two floating-point values are approximately equal within a relative tolerance.
- PT_UNIT_ASSERT_THROW(expr, ExType) — asserts that expr throws an exception of type ExType.
- PT_UNIT_ASSERT_NOTHROW(expr) — asserts that expr does not throw.
- PT_UNIT_FAIL(msg) — fails unconditionally with a message.
Protocol and Data-Driven Testing
This is the base class for protocols that can be used to run a test suite. The default implementation will simply run each registered test of the test suite without passing it any data. Implementors need to override the method TestProtocol::run to control the order and frequency of test method execution. This is useful to repeat tests, interleave them with waits, or implement stress-test patterns.
A protocol is assigned to a TestSuite through the constructor or via TestSuite::setProtocol().
Test methods in a TestSuite can also take arguments for data-driven testing. The protocol calls TestSuite::runTest() with Pt::SerializationInfo objects to pass different data each time.
Automatic Test Registration
Tests can be registered easily with the RegisterTest<> class template to an Unit::Application at program initialisation. A typical example looks like this:
The constructor of the RegisterTest class template will register an instance of its template parameter to the application.
Running Test Applications
The Application class serves as the environment for running unit tests. Tests are registered at program start using Pt::Unit::RegisterTest. A Reporter can be attached to process test events such as printing results to the console or writing log files.
The simplest way to provide a main() function is to include TestMain.h in exactly one source file of the test executable. It creates an Application, attaches a BriefReporter for console output and supports the following command line arguments:
-h— prints a list of all registered tests.-t<name>— runs only the test with the given name.-f<file>— additionally writes test output to a log file.
When executed without arguments, all registered tests are run. The exit code equals the number of errors, so a successful run returns 0.
For more control over reporter setup or test execution, a custom main() function can be written instead of including TestMain.h.
Reporting Test Results
This class is the base class for all reporters for test events. It lets the implementor override several virtual methods that are called on perticular events during the test. Reporters can be made to print information to the console or write XML logs.