This is similar to: https://stackoverflow.com/questions/1278831/unit-tests-in-production-release-code# but more specific.

At the moment the DLL I ship and the DLL I use for unit testing have different access. When doing unit testing, since I test each individual functions/classes, I add __declspec(dllexport) to functions/classes that would be otherwise inaccessible.



  • Limits access to the end users. The company is planning to ship the product in a library form and I think this is important.
  • For the packaged application, it checks external symbols during build. So there is reduced risk having inaccessible external error causing bug in shipped products.
  • Can you be more specific about what you mean by "matter?" Feb 25, 2018 at 5:10
  • @RobertHarvey changed the title to "What are the dangers..." I just want to know why someone shouldn't do this cause I can't fathom the cons of doing this. Feb 25, 2018 at 5:14
  • Off the top of my head, 1. It's not the same DLL, so there's always a small risk that you deploy the wrong one, and 2. It's not the same DLL, so there's always a small risk that you're going to get different behavior than that which you tested. Also, 3. the prevailing point of view about unit testing is that, if a method is not already exposed publicly, you don't need to unit test it separately. Instead, test it indirectly through the public methods that are already exposed. Feb 25, 2018 at 5:35
  • I suppose both DLLs are compiled in Release mode, and that the only difference between the DLLs are the exported symbols? (DLLs compiled in Debug mode uses the Debug version of C++ Standard library, which can have behavioral and performance differences, especially if there are bugs in code written by your company.)
    – rwong
    Feb 25, 2018 at 9:09
  • @rwong yes I usually run the unit test on release build. However the actual shipping binary is different. Feb 25, 2018 at 11:04

1 Answer 1


It is great to unit test things, even those that are are not externally accessible.

You still need to test what you're shipping — because of compiler bugs, and configuration problems, etc...

So, your unit tests on the internal items give you coverage on lines of code, and, hopefully your integration tests cover what you're actually shipping and have externally exposed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.