标签：c unit-testing visual-studio-2010 googletest cppunit

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

我看到单元测试的两个主要区域覆盖了这个设置：

>测试内部组件(可能通过COM暴露也可能不暴露)
>测试外部暴露的组件(也称测试暴露的接口)

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

从我一直在进行的研究看来,“规范”似乎是将单元测试放在一个不同的子项目中,并让主要的解决方案为单元测试提供钩子以访问内部组件.通过此设置,单元测试解决方案将为正在测试的解决方案设置依赖性.这真的是“规范”,还是有很多人把他们的单元测试框架放在正在测试的解决方案中(也就是单元测试不是子项目,而是松散的cpps #ifdef’d out,如果没有提供预处理器标志)？

目前使用的单元测试框架似乎是cppunit,我正在考虑将其转换为gtest并尝试将所有内容移动到不同的子项目中,但我想确保从长远来看这些努力是值得的.

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

所以我的问题是：

>是否将单元测试放在单独的(子)项目中并从要测试的源中公开组件(通过挂钩,暴露类定义等)？
>从COM DLL公开内部组件的最佳方法是什么？
>为内部组件启用__declspec的预处理程序标志是否会被测试？有没有其他人在他们的单元测试中做到这一点,正常操作期间正在测试的项目通常不会暴露？

感谢您的评论！

解决方法:

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

所以解决方案看起来像：

MainSolution

> ProjCommonLib
> ProjExportsLib
> ProjImportsLib
> ProjOtherStuffLib
> COMDLL-Proj
> UnitTestsFolder

> ProjCommonLibTests
> ProjExportsLibTests
> ProjImportsLibTests
> ProjOtherStuffLibTests
> COMDLL-ProjTests

这种类型的设置允许单元测试在静态库上设置依赖关系,并且无需处理__declspec即可完全访问内部.这似乎更清晰,因为DLL没有模块化的任何性能损失,因为其他库只是静态库.

我把它作为一个“答案”,看它是否得到任何投票(又名,“这个答案是一个很好的方法,也是我做的”).如果这是一个糟糕的解决方案,请发布您的答案.

标签：c,unit-testing,visual-studio-2010,googletest,cppunit
来源： https://codeday.me/bug/20190903/1794612.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。