Using Boost.Test in a dynamically loaded library

We are trying to write units tests using the Boost.test framework which
involve dynamic loading of libraries (i.e. lt_dlopen on Linux or
LoadLibrary on Windows) and doing tests using the Boost test tools in
code inside the dynamically loaded library.
Does Boost.Test support this?
We have run into problems when trying to use the quick-and-dirty
"include" option for defining the Boost.Test symbols. Dynamically loaded
libraries may not contain undefined symbols, and including the
implementation headers such as

Florian Winter
We are trying to write units tests using the Boost.test framework which involve dynamic loading of libraries (i.e. lt_dlopen on Linux or LoadLibrary on Windows) and doing tests using the Boost test tools in code inside the dynamically loaded library.
Does Boost.Test support this?
Yes. You can do this. you can also use console_test_runner and execute test modules built as dlls.
We have run into problems when trying to use the quick-and-dirty "include" option for defining the Boost.Test symbols. Dynamically loaded libraries may not contain undefined symbols, and including the implementation headers such as
in both the dynamically loaded library and the main application seems to lead to duplicate symbols. In particular, if we use BOOST_CHECK macros
Yes. you can't do this.
We would like to know what is the "best" practice to use Boost.Test in unit tests that require dynamic loading of libraries and tests being made in both application code and dynamic library code.
Use dynamic library version of Unit test Framework. It will work perfectly fine in this scenario. Gennadiy

Thanks for your reply. I have considered another option that might be easier for us if it works: One of the options described in the documentation about compiling the unit test framework is "Including sources directly into test module project". This would normally lead to the same problems as the "include" option, however, we could include the Boost.Test sources into a separate shared library that we build using our own build system. Both our dynamically loaded library and our main application would link against this shared library to make sure the Boost.Test symbols are defined exactly once. The benefit would be that we could use our own build system instead of treating Boost.Test as an external library. This would make things a lot easier for us because we have to support many platforms. Do you think this would work? Or are there some other things to keep in mind or problems when building Boost.Test as a shared library that was not built in the standard way (i.e. using bjam on each platform)? Best regards, Florian Winter
participants (2)
-
Florian Winter
-
Gennadiy Rozental