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 multi-file test module. 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 BOOST_TEST_ALTERNATIVE_INIT_API. If flag isn't defined you are required to match the original specification. If you define the flag BOOST_TEST_ALTERNATIVE_INIT_API 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.