Re: [Boost-users] Boost Unit Testing of DLL's

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.
Johan,

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. 
http://msdn.microsoft.com/en-us/library/yx9zd12s%28v=VS.90%29.aspx

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 
DllMain.

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.