Boost C++ Libraries

If you are reading this chapter, this means that the wide range of tools and interfaces covered in the previous sections are not sufficient for the testing scenario you have in mind. You are here to bend the Unit Test Framework to your will and ... we are not going to stop you. Instead we'll try to guide you so that some dark corners do not look scary.

In most cases the Unit Test Framework is going to be supplied for you either as part of your system libraries or set of libraries used by your companies. Yet if you are facing the necessity to build your own static or dynamic library of the Unit Test Framework or need to customize the build for any reason, section Building the Unit Test Framework covers all the necessary steps.

To streamline the experience of setting up your test module, the Unit Test Framework provides some default initialization logic for them. Usually the default test module initialization will work just fine, but if you want to implement some custom initialization or change how default initialization behaves you need to first look in Test module initialization section. Here you'll learn about various options the Unit Test Framework provides for you to customize this behavior.

The part of the framework which loads, initializes and executed your test module is called the Test Runner. Each usage variant comes with default test runner. If, instead, you prefer to implement your own entry point into the test module (for example if you need to implement the main function yourself and not use the one provided by the Unit Test Framework, you need to learn about Unit Test Framework interfaces involved in test runners operations. These are covered in the Test runners section. Let me reiterate that you only need to this section if regular regular options for customization of initialization logic like fixtures or decorators are not sufficient for your purposes.