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 <boost/test/included/unit_test.hpp> extern "C" { __declspec(dllexport) bool init_unit_test() { boost::unit_test::framework::master_test_suite().p_name.value = "Imaging_Utilities tests"; return true; } } __declspec(dllexport) boost::unit_test::test_suite * init_unit_test_suite(int,char * * const) { boost::unit_test::framework::master_test_suite().p_name.value = "Imaging_Utilities tests"; return(&boost::unit_test::framework::master_test_suite()); } In the cpp's implementing the test's it looks like: #define BOOST_TEST_INCLUDED #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_SUITE(Polygon_Tests) BOOST_AUTO_TEST_CASE(Polygon_Tests_Clockwize_001) { . . Maybe you can see if I am doing something wrong in the above? DELAY LOADING APPROACH This was actually my preferred approach but when I specify boost_unit_test_framework-vc100-mt-gd-1_46_1.dll to be delay loaded, I can't even load my DLL. I don't even get to the DLL_PROCESS_ATTACH in my DLL. It looks like it is because macros like BOOST_AUTO_TEST_SUITE is designed to call functions (at load time) which seems to be implemented in boost_unit_test_framework-vc100-mt-gd-1_46_1.dll. The way I implemented the dynamic load was by adding the following code to the stdafx.cpp #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> extern "C" { __declspec(dllexport) bool init_unit_test() { boost::unit_test::framework::master_test_suite().p_name.value = "Imaging_Utilities tests"; return true; } } In the cpp's implementing the test's it looks like: #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_SUITE(Polygon_Tests) BOOST_AUTO_TEST_CASE(Polygon_Tests_Clockwize_001) { . . When the boost_unit_test_framework-vc100-mt-gd-1_46_1.dll is available all the tests runs nicely but without the DLL will not load not even if boost_unit_test_framework-vc100-mt-gd-1_46_1.dll is specified to be delay loaded. If possible we would prefer a solution like this as it would minimize compile time and the size of the binaries. So I am most curious to suggestions I should try to get this running. Best regards Johan Doré

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