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 <boost/test/included/unit_test.hpp> in both the dynamically loaded library and the main application seems to lead to duplicate symbols. In particular, if we use BOOST_CHECK macros in both the main application, everything works fine. However, if we use BOOST_CHECK macros in the dynamically loaded library, we get an exception with the following comment: can't use testing tools before framework is initialized We suspect that this is caused by Boost.Test global symbols being defined multiple times - once in the application and once in the dynamic library. 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. It must work on Linux (using libraries created with libtool and libltdl for dynamic loading) and Windows (using DLLs and LoadLibrary for dynamic loading). Is this even possible and has it been tested before? Would using a static or shared library version of Boost.Test solve our problem? Are there any other potential pitfalls that we should be aware of? Thanks in advance for your help. Best Regards, Florian Winter, Motama GmbH -- Florian Winter Software-Entwickler
Florian Winter <fw <at> motama.com> writes:
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 <boost/test/included/unit_test.hpp> 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