UTF"> ]>

Usage variants The &utf; presents you with 4 different variants how it can be used. The static library variant The dynamic library variant The single-header variant The external test runner variant Unlike the Buridan's donkey though, you shouldn't have problems deciding which one to use, since there are clear reasons why would you prefer each one. In most cases to compile a test module based on the &utf; all you need to include is just the single header boost/test/unit_test.hpp. This header includes internally most of the other headers that contains the &utf; definitions. Some advanced features, like the floating point comparison or the logged expectations testing, are defined in independent headers and need to be included explicitly.

Static library The &utf; can be built into a static library. If you opt to link a test module with the standalone static library, this usage is called the static library variant of the &utf;. The test runner supplied with this variant required you to implement the test module initialization function that matches one of the two specifications depending on the compilation flag . If flag isn't defined you are required to match the original specification. If you define the flag during a test module compilation you are required to use the alternative initialization function specification. The &utf; provides an ability to automatically generate an empty test module initialization function with correct specification if no custom initialization is required by a test module. If you opted to use an alternative initialization API, for a test module to be able to link with prebuilt library, the flag has to be defined both during library and a test module compilation.

Dynamic library In the project with large number of test modules the static library variant of the &utf; may cause you to waste a lot of disk space, since the &utf; is linked statically with every test module. The solution is to link with the &utf; built into a dynamic library. If you opt to link a test module with the prebuilt dynamic library, this usage is called the dynamic library variant of the &utf;. This variant requires you to define the flag either in a makefile or before the header boost/test/unit_test.hpp inclusion. The test runner supplied with this variant requires you to implement the test module initialization function that matches the alternative initialization function signature. The &utf; provides an ability to automatically generate an empty test module initialization function with correct signature if no custom initialization is required by a test module. The name of the test module initialization function is not enforced, since the function is passed as an argument to the test runner.

Single header If you prefer to avoid the standalone library compilation, you should use the single-header variant of the &utf;. This variant is implemented, as it follows from its name, in the single header boost/test/included/unit_test.hpp. An inclusion of the header causes the complete implementation of the &utf; to be included as a part of a test module's source file. The header boost/test/unit_test.hpp doesn't have to be included anymore. You don't have to worry about disabling auto-linking feature either. It's done in the implementation header already. This variant can't be used with the . Otherwise it's almost identical from the usage prospective to the static library variant of the &utf;. In fact the only difference is the name of the include file: boost/test/included/unit_test.hpp instead of boost/test/unit_test.hpp. The test runner supplied with this variant requires you to implement the test module initialization function that matches one of the two specifications depending on the compilation flag . If flag isn't defined you are required to match the original specification. If you define the flag during a test module compilation you are required to use the alternative initialization function specification. The &utf; provides an ability to automatically generate an empty test module initialization function with correct specification if no custom initialization is required by a test module.

External test runner All other usage variants employ the build-in test runners. If you plan to use an external test runner with your test module you need to build it as a dynamic library. This usage of the &utf; is called the external test runner variant of the &utf;. The variant requires you to define the flag either in a makefile or before the header boost/test/unit_test.hpp inclusion. An external test runner utility is required to link with dynamic library. If an external test runner is based on the test runner built in to the dynamic library (like the standalone boost_test_runner utility supplied by the &utf;), it requires you to implement the test module initialization function that matches the alternative initialization function signature. The &utf; provides an ability to automatically generate an empty test module initialization function with correct signature if no custom initialization is required by a test module. An advanced test runner doesn't have to be based on the build-in one and may require a different test module initialization function signature and/or name.