对 DLL 中的非导出类进行单元测试
我们使用 Visual Studio 2008 开发 C++ 应用程序，并使用 Boost.Test 进行单元测试。目前，我们有一个单独的解决方案，其中包含我们的单元测试。
我们的许多核心解决方案项目都生成 DLL。我们的测试覆盖范围有限，因为我们无法测试非导出的类。
关于如何测试这些，我有两个想法：
- 导出所有内容
- 将测试放入 DLL（同一项目和解决方案）中并使用 Boost.Test 的外部运行程序
我不完全确定缺点是什么。上面的第 1 点破坏了模块级封装，而第 2 点可能会导致更大的 DLL，除非可以仅在某些配置中包含测试代码。
那么，上述方法有没有严重的缺点，或者你能想到其他解决方案吗？
We develop a C++ application using Visual Studio 2008 and unit test using Boost.Test. At the moment, we have a separate solution which contains our unit tests.
Many of our projects in the core solution produce DLL's. We're limited in test coverage because we cannot test non-exported classes.
I have two ideas on how these could be tested:
- Export everything
- Put the tests inside the DLL (same project and solution) and use Boost.Test's external runner
I'm not entirely sure what the drawbacks would be. Number 1 above breaks module level encapsulation, and number 2 could result in a much larger DLL, unless it's possible to only include the test code in certain configurations.
So, are there any severe drawbacks to the above methods, or can you think of other solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
扩展 Tom Quarendon 对这个问题的回答，我使用了 Simon Steele 的回答的一个轻微变体：
#include。$(IntDir)添加到“附加库目录”。.obj文件添加到“附加依赖项”中。同样，唯一的维护开销是单元测试的标准开销 - 创建对要测试的单元的依赖关系。
Expanding on Tom Quarendon's answer to this question, I have used a slight variant of Simon Steele's response:
#include <header/in/source/project.h>.$(IntDir)to the Additional Library Directories..objfiles to the Additional Dependencies.Again, the only maintenance overhead is the standard one for unit tests - to create the dependency on the unit(s) you want to test.
我为此使用的解决方案是将相同的非导出代码也构建到我的测试 DLL 中。这确实增加了构建时间，并且意味着将所有内容添加到两个项目中，但节省了导出所有内容或将测试放入主产品代码中的时间。
另一种可能性是将非导出代码编译到一个 lib 中，该库由带有导出的 DLL 和单元测试项目使用。
The solution I use for this is to build the same non-exported code into my tests DLL as well. This does increase build time and means adding everything to both projects, but saves exporting everything or putting the tests in the main product code.
Another posibility would be to compile the non-exported code into a lib which is used by both the DLL with exports, and the unit test project.
也在寻找解决方案，也许以下内容会更容易维护。
将新的构建配置（例如“单元测试调试”）添加到 DLL 项目，并将配置类型更改为“静态库.lib”（“常规”->“配置类型”）。
然后只需在该项目上添加单元测试的依赖项，现在当您使用新的构建配置“单元测试调试”时，所有内容都应该链接在一起。
如果您使用发布版本进行单元测试，那么您需要添加另一个具有发布优化的配置。
因此，该解决方案的优点是：
缺点：
更新：
我们实际上最终使用了不同的方法。
我们为每个现有项目添加了新的“测试调试”/“测试发布”配置。
对于 .exe/.dll 项目，我们禁用原始 main.cpp 的编译，并将其替换为实例化测试框架的配置（例如gtest）并运行所有测试，测试位于单独的 .cpp 文件中，这些文件也在常规配置（发布/调试）中排除在编译之外，并且仅在测试配置中启用。
对于 .lib 项目，我们还有新的“测试调试”/。 “测试发布”配置和在那里，我们将静态库转换为 .exe 文件，并提供一个 main.cpp，它实例化测试框架并运行测试，并且测试相关文件本身被排除在发布/调试配置的编译之外。
Was searching a solution as well, maybe the following will be easier to maintain.
Add a new build configuration e.g. "Unit testing Debug" to the DLL project and change the Configuration Type to be "Static Library .lib" ("General"->"Configuration Type").
Then just add a dependency of your unit tests on this project, now everything should link together when you use new build configuration "Unit testing Debug".
If you are using release builds for unit tests then you need to add another configuration with release optimizations.
So the benefits of this solution are:
Drawbacks:
Update:
We actually ended up using a different approach.
We added new "Test debug"/"Test release' configurations for every existing project that we have.
For .exe/.dll projects we disable the original main.cpp from compiling and replaced it with the one that instantiates the test framework (e.g. gtest) and runs all the tests, the tests are in separate .cpp files which are also excluded from compilation in regular configurations (Release/Debug) and enabled only in Test configurations.
For .lib projects we also have new "Test debug"/"Test release" configurations and there we convert the static library to be an .exe file and provide a main.cpp which instantiates the testing framework and runs the tests and tests themselves. Test related files are excluded from compilation on Release/Debug configurations.
尝试在所有文件都包含的地方进行如下定义：
并使用它代替 dllexport，如下所示：
然后您将能够关闭用于构建发布 DLL 的标志，但将其保留在一个单元中 -可测试的DLL。
Try making a define such as the following somewhere all files will include:
And use it in place of the dllexport, like this:
Then you will be able to turn off the flag for building a release DLL, but keep it on for a unit-testable DLL.