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.