c++ - 我在哪里放置单元测试源并公开内部组件？

Question

我正在接手一个通过 ATL 公开组件的项目。

我看到此设置要涵盖单元测试的两个主要方面:

• 测试内部组件(可能会也可能不会通过 COM 公开)
• 测试外部暴露的组件(也称为测试暴露的接口(interface))

目前，该项目的所有内部组件都在解决方案中进行了单元测试。它们由预处理器标志启用，该标志将其编译并在您运行时执行。

从我一直在做的研究来看，“规范”似乎是将单元测试放在不同的子项目中，并为单元测试提供主要解决方案供应 Hook 以访问内部组件。使用此设置，单元测试解决方案将设置对被测试解决方案的依赖性。这真的是“规范”吗？还是有很多人将他们的单元测试框架放在正在测试的解决方案中(又名单元测试不是一个子项目，而是松散的如果未提供预处理器标志，则 #ifdef 的 cpps)？

目前使用的单元测试框架似乎是 cppunit，我正在考虑将其切换到 gtest 并尝试将所有内容移动到不同的子项目中，但我想确保长期的努力是值得的运行。

我想到的一种方法是 __declspec 要测试的类，它们仅在指定预处理器定义时公开。然后单独的单元测试子项目将使该预处理器告诉主要解决方案公开内部。我只是不确定这是否是最佳路线。

所以我的问题是:

1. 将单元测试放在单独的(子)项目中并公开来自将要测试的源的组件(通过 Hook 、公开类定义等)的规范吗？
2. 从 COM DLL 公开内部组件的最佳方法是什么？
3. 为要测试的内部组件启用__declspec 的预处理器标志是否是个坏主意？有没有其他人在他们的单元测试中这样做过，其中被测试的项目在正常操作期间通常不会暴露？

感谢评论!

Answer 1

另一个团队的人说他们的团队将所有单元测试放在单独的项目中，并且能够通过静态库公开内部结构。这对我来说很有意义，因为它有助于模块化并提供许多其他好处。因此，每个主要的代码耦合都是一个静态库(不过分 ;) )并且对于每个静态库，您将有一个单独的单元测试解决方案。然后您的主 DLL 变成一个薄包装器，它公开了必要的项目。

所以解决方案看起来像:

主要解决方案

• 项目公共(public)库
• 项目导出库
• 项目导入库
• ProjOtherStuffLib
• COMDLL-项目
• 单元测试文件夹
  • ProjCommonLibTests
  • ProjExportsLibTests
  • ProjImportsLibTests
  • ProjOtherStuffLibTests
  • COMDLL-ProjTests

这种类型的设置允许单元测试设置对静态库的依赖，并且可以完全访问内部结构，而无需处理 __declspec。这看起来干净多了，因为 DLL 不会因模块化而对性能造成任何影响，因为其他库就是静态库。

我将其作为一个“答案”，看看它是否得到任何赞成票(也就是“这个答案是一个很好的方法，我也是这样做的”)。如果这是一个糟糕的解决方案，请发布您的答案。