Boost Test
Library
Introduction
Components
Execution Tools
Test Tools
Design
Open Issues
Portability
Acknowledgements
A matched set of tools for writing test programs, and controlling their
runtime execution.
The execution tools are also useful in some production (non-test)
environments.
Near zero dependencies between the tools allow mix-and-match tool
combinations without paying for features not used.
- Execution Tools - Basic
exception and error detection and reporting for use in both production and
test programs.
Used directly by production programs, the Execution Tools' replacement
main() function is also the default lowest layer for the Test Tools.
- Test Tools - Simple test facilities for simple test
program needs.
Used directly by simple test programs, the Test Tools are also used as the
default lower layer for the Unit Test Tools.
- Unit Test Tools (To be supplied) - More complex test facilities for constructing
complete test suites and meeting other more advanced testing needs.
See Boost Test Library Design.
- Better support for specific platforms. For both Unix and Windows, it is possible to write platform specific code that detects
and reports additional errors, such as an attempt to divide by zero or an
addressing exception. The current plan is to defer implementation
until after formal review and initial version acceptance.
- More explicit exception messages on platforms where RTTI typeid is
meaningful.
- Instructions for users wishing their own exception types be handled like
catch_exceptions().
- A volunteer is needed to develop a Unit Test library for Boost.
- It would be useful to be able to compare test output files to the expected
output files. A volunteer is needed.
Because the Boost Test Library is critical for porting and testing Boost libraries, it has been written to be very conservative in
its use of C++ features, and to keep dependencies to a bare minimum..
Tests have been run (and work) under numerous compilers.
Ed Brey, Kevlin Henney, Ullrich Koethe, and Thomas Matelich provided very
helpful comments during development. Dave Abrahams, Ed Brey, William Kempf, Jens
Maurer, and Wilka suggested numerous improvements during the Formal
Review. Jens Maurer was the review manager. Beman Dawes is the
developer and maintainer.
© Beman Dawes 2001
Revised 28 February, 2001