31

我们使用 Visual Studio 2008 开发 C++ 应用程序并使用 Boost.Test 进行单元测试。目前，我们有一个单独的解决方案，其中包含我们的单元测试。

我们在核心解决方案中的许多项目都会生成 DLL。我们的测试覆盖率有限，因为我们无法测试非导出的类。

关于如何测试这些，我有两个想法：

  1. 导出一切
  2. 将测试放在 DLL 中（相同的项目和解决方案）并使用 Boost.Test 的外部运行器

我不完全确定缺点是什么。上面的数字 1 破坏了模块级别的封装，而数字 2 可能会导致更大的 DLL，除非可以仅在某些配置中包含测试代码。

那么，上述方法是否存在严重的缺陷，或者您能想到其他解决方案吗？

4

4 回答 4

16

扩展Tom Quarendon 对这个问题的回答，我使用了 Simon Steele 回答的一个轻微变体：

  • 创建一个测试项目（使用您喜欢的任何测试框架，我使用CppUnit）。
  • 在您的 test_case.cpp 中，#include <header/in/source/project.h>.
  • 在测试项目属性中：
    • 在 Linker->General 中，将源项目添加$(IntDir)到 Additional Library Directories。
    • 在 Linker->Input 中，将.obj文件添加到 Additional Dependencies。
  • 在 Project->Project Dependencies 中将测试项目的依赖添加到源项目。

同样，唯一的维护开销是单元测试的标准开销——创建对要测试的单元的依赖关系。

于 2014-06-17T17:02:02.757 回答
4

我为此使用的解决方案是将相同的非导出代码也构建到我的测试 DLL 中。这确实会增加构建时间并意味着将所有内容添加到两个项目中，但可以节省导出所有内容或将测试放入主要产品代码中。

另一种可能性是将未导出的代码编译成一个库，该库由带导出的 DLL 和单元测试项目使用。

于 2011-03-31T08:16:08.183 回答
2

也在寻找解决方案，也许以下会更容易维护。

向 DLL 项目添加一个新的构建配置，例如“单元测试调试”，并将配置类型更改为“静态库 .lib”（“常规”->“配置类型”）。

然后只需在此项目上添加单元测试的依赖项，现在当您使用新的构建配置“单元测试调试”时，所有内容都应该链接在一起。如果您使用发布版本进行单元测试，那么您需要添加另一个具有发布优化的配​​置。

所以这个解决方案的好处是：

  • 维护成本低
  • 单个 DLL/静态库项目
  • 不必手动链接到 .obj 文件

缺点：

  • 额外的配置文件将需要在您的构建环境 (CI) 中进行一些更改
  • 更长的编译时间

更新：我们实际上最终使用了不同的方法。

我们为我们拥有的每个现有项目添加了新的“测试调试”/“测试发布”配置。

对于 .exe/.dll 项目，我们禁用原始 main.cpp 编译并将其替换为实例化测试框架（例如 gtest）并运行所有测试的那个，测试位于单独的 .cpp 文件中，这些文件也被排除在外在常规配置（发布/调试）中编译并且仅在测试配置中启用。

对于 .lib 项目，我们还有新的“测试调试”/“测试发布”配置，我们将静态库转换为 .exe 文件，并提供一个 main.cpp 实例化测试框架并自行运行测试和测试。测试相关文件被排除在发布/调试配置的编译之外。

于 2015-08-25T12:40:08.083 回答
0

尝试在所有文件都包含的地方进行如下定义：

#define EXPORTTESTING __declspec(dllexport)

并使用它代替 dllexport，如下所示：

class EXPORTTESTING Foo 
{
 ...
};

然后，您将能够关闭用于构建发布 DLL 的标志，但为可单元测试的 DLL 保持开启。

于 2013-01-17T20:30:02.770 回答