Boost logo

Boost Test Library

"Test everything that could possibly break"

XP maxim

Introduction
Components

Execution monitor
Program Execution Monitor
Test Tools
Test Execution Monitor
Unit Test Framework
Minimal Test

FAQ
Design

Migration guide
Open Issues
Portability
Acknowledgements

Introduction

The Boost Test Library provides a matched set of components for writing test programs, organizing tests in to simple test cases and test suites, and controlling their runtime execution. The Program Execution Monitor is also useful in some production (non-test) environments.

reference to the top

Components

  • Execution Monitor - a basic exception and error detection and reporting facility for use in both production and test programs. The Execution Monitor calls a user-supplied function and reports all caught runtime exceptions. It is used internally by other Boost Test Library components. It also could be used in some production environment to make controlled calls of functions which might otherwise crash the program.
  • Program Execution Monitor - a simple helper facility to be used to monitor a program execution. The Program Execution Monitor provides the main() function and uses the Execution Monitor to control a program execution. It should be used in production environment to produce uniform error reports. To control programs working in test environment, use the Test Execution Monitor instead.
  • Test Execution Monitor - causes a test program to run in a monitored environment. The Test Execution Monitor provides the main() function to control a simple test program execution and allows to use the Test Tools to implement test logic. It is intended to be used in test environment. To control production code execution use the Program Execution Monitor.
  • Unit Test Framework - a framework that simplifies writing and organizing test cases. The framework supports test cases written as simple free functions or member functions and organizes them into a tree of test suites. The framework allows to use the Test Tools to implement a test cases and provides a facility to manage a log report level and a result report level.
  • Minimal testing - simple facility designed to provide the functionality provided before by the original version of Boost.Test.The same as the Test Execution Monitor it causes the test ptogram to run in a monitored environment. In addition it defines several simple test tools that behave similarly to ones defined in Test Tools. Minimal testinf facility does not require linking with external components, so could be a component of choice for simple and quick testing needs.
reference to the top

FAQ

See Boost Test Library FAQ.

Design

See Boost Test Library Design.

Boost.Test migration guide

This version of Boost.Test library substitute the original testing library used in a Boost. These are several simple steps you need to follow to smoothly migrate to the latest software.

If your code were using the original version of cpp_main facility, to migrate you will need to delete the inclusion of the <boost/test/cpp_main.cpp>, since this file is not present any more. After that you have following choices:

  • Link with Program Execution Monitor (exact library name depends on compiler you are using, but most probably it will be libprg_exec_monitor.lib).
  • Include <boost/test/included/prg_exec_monitor.hpp>, in which case you need not link with precompiled component but it may incur probably some compile time overhead.

If your code were using the original version of test_main and test tools facilitates of Boost.Test library, to migrate to use of latest one you have following choices:

  • Without changing of the code that were using Boost.Test facilities link with Test Execution Monitor (exact library name depends on compiler you are using, but most probably it will be libtest_exec_monitor.lib).
  • Include <boost/test/included/test_exec_monitor.hpp>, in which case you need not link with precompiled component but it may incur probably some compile time overhead. Definition of BOOST_INCLUDE_MAIN could be deleted either.
  • Include <boost/minimal.hpp>, in which case you need not link with precompiled component and it most probably does not incur a compile time overhead, but you will be limited ti the set of features defined in the original test library. Definition of BOOST_INCLUDE_MAIN could be deleted either. Would you decide in a future to use any of newer Boost.Test features you will be enforced to snitch to one the two chaises above.

Open Issues

  • What dependencies will we tolerate in Boost Test Library? Also we need means to overcome this restriction for extensions.
  • Memory usage test tools.
  • Performance test tools.
  • Facilities to allow testing of template function for the provided type list.
  • How to implement compilability checks.
  • Selective test cases run: ways to define by user and notify the framework.
  • Command line argument processing facility: external or internal, simple or advanced?
  • Integration of the unit test framework into the Boost Build System.
  • Support for the testing of multithreaded programs.
  • Make BOOST_TEST_CLOSE print values properly
  • Timeout implementation on Win32 platform.
  • Need to separate reference and tutorial material
  • Unit Test Framework extension should be documented
  • Should the execution monitor page contain an example?
reference to the top

Portability

Because the Boost Test Library is critical for porting and testing Boost libraries, it has been written to be extremely conservative in its use of C++ features, and to keep dependencies to a bare minimum.

Tests have been run (and work) under numerous compilers.

Acknowledgements

Original Test Library:

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.

Second Release:

Beman Dawes and Ullrich Koethe started the library. Fernando Cacciola, Jeremy Siek, Beman Dawes, Ullrich Koethe, Dave Abrahams suggested numerous improvements during the Formal Review. Jeremy Siek was the review manager. Dave reference to the top Abrahams edited this documentation. Beman Dawes was a great help in both final testing and merging library with rest of the boost. Gennadiy Rozental is the developer and maintainer.