Introduction

The acceptance test makes the customer satisfied that the software provides the business value that makes them willing to pay for it. The unit test makes the programmer satisfied that the software does what the programmer thinks it does

--XP maxim

What is the first thing you need to do when you start working on new library/class/program? That's right - you need to start with the unit test module (I hope you all gave this answer!). Occasional, simple test may be implemented using asserts. But any professional developer soon finds this approach lacking. It becomes clear that it's too time-consuming and tedious for simple, but repetitive unit testing tasks and it's too inflexible for most nontrivial ones.

The Boost Test Library Unit Test Framework (further in the documentation referred by the acronym UTF) provides both an easy to use and flexible solution to this problem domain: C++ unit test implementation and organization.

Unit testing tasks arise during many different stages of software development: from initial project implementation to its maintenance and later revisions. These tasks differ in their complexity and purpose and accordingly are approached differently by different developers. The wide spectrum of tasks in a problem domain cause many requirements (sometimes conflicting) to be placed on a unit testing framework. These include:

Writing a unit test module should be simple and obvious for new users.
The framework should allow advanced users to perform nontrivial tests.
Test module should be able to have many small test cases and developer should be able to group them into test suites.
At the beginning of the development users want to see verbose and descriptive error message, whereas during the regression testing they just want to know if any tests failed.
For a small test modules run time should prevail over compilation time: user don't want to wait a minute to compile a test that takes a second to run.
For long and complex tests users want to be able to see the test progress.
Simplest tests shouldn't require an external library.
For long term usage users of a unit test framework should be able to build it as a standalone library.

The UTF design is based on above rationale and provides versatile facilities to:

Simplify writing test cases by using various testing tools.
Organize test cases into a test tree.
Relieve you from messy error detection, reporting duties and framework runtime parameters processing.

The UTF keeps track of all passed/failed testing tools assertions, provides an ability to check the test progress and generates a result report in several different formats. The UTF supplies command line test runners that initialize the framework and run the requested tests. Depending on the selected compilation flags the function main() default implementation, that invoke the supplied test runner, can be generated automatically as well.

The UTF is intended to be used both for a simple and non trivial testing. It is not intended to be used with production code. In this case the Program Execution Monitor is more suitable.

Given the largely differing requirements of new and advanced users, it is clear that the UTF must provide both simple, easy-to-use interfaces with limited customization options and advanced interfaces, which allow unit testing to be fully customized. Accordingly the material provided in this documentation is split into two sections:

The User's Guide: covers all functionality that doesn't require knowledge of the UTF internals
The Advanced User's Guide: covers all implementation details required for a user to understand the advanced customization options available in the UTF, and for a user interested in extending the testing framework.

For those interested in getting started quickly please visit collection of examples presented in this documentation.