Re: [Boost-users] Boost Unit Testing of DLL's
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.
STATIC LIBRARY APPROACH
I have tried to link against the static library but for some reason ( Probably my novice level on this ) the console_test_runner-d.exe just tells me that:
1>EXEC : Test setup error : test tree is empty
The way I implemented the static link was by adding the following code to the stdafx.cpp
#include
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.
participants (2)
-
Johan Doré
-
Tyler Weston