Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost Unit Testing of DLL's
From: Tyler Weston (tyler.weston_at_[hidden])
Date: 2011-05-27 16:03:23

On 5/27/2011 1:50 PM, Johan Doré wrote:
> Hi,
> Thanks for the quick response.
> The reason why we would like to have the test code compiled into the modules themselves is simply because it would allow us to test functions and classes only available to the modules without having to export them out of the DLL. But also because it would limit the number of projects we have to compile. Currently without having separate unit testing projects we have more than 100 individual DLL's to which we want to apply UTF.

If you add a "delay load" flag for the boost UTF DLL, you should be able
to ship testing code in your DLL without providing the UTF DLL to
customers. This instructs the compiler to only look for the UTF DLL when
the testing framework attempts to make a call. As long as your users
don't try to call your test hooks, it should work out.

However, I don't like shipping testing code. Another approach that I
have had success with involves a 2 step build for the shipping DLL.
First, build a static lib with all of your actual implementation. Build
your DLL by compiling the static lib with DLL-only features such as

If you build these two binaries, you can apply unit testing to the
static lib, without having to export all of your symbols. You can then
apply application testing to the DLL. It may seem problematic to apply a
set of tests to a binary you will end up throwing away, but I have yet
to see a case where implementation behavior differed between the static
and dynamic libs. Important cases will be double checked in the
application-level testing. The risk that one of these bugs eventually
shows up is outweighed for me by the fact that i can keep testing code
separate from shipping code, and still have fast builds, since we only
build the implementation once.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at