测试代码应与源/生产代码分开

Question

即使我们有一个Makefile或类似的东西,在运送产品时将测试代码分开.在我看来,它们应该是分开的,但我并不完全相信为什么

Answer 1

是的,它们应该是分开的(文件夹,最好是项目).一些原因:

• GREP.在生产源中搜索字符串更容易.
• 代码覆盖率.想象一下,尝试指定要包含哪些文件.
• 不同的标准.您可能只想在生产代码上运行静态分析等.
• 简化的makefile /构建脚本.

现代IDE允许您处理来自单独项目/文件夹的代码,就好像它们是相邻的一样.

您可以做的最糟糕的事情是在同一个文件中包含测试和生产代码(使用条件编译,不同的入口点等).这不仅会让尝试阅读代码的开发人员感到困惑,而且总是冒着意外发送测试代码的风险.

Answer 2

既然我有机会与这两种方法(工作分开,并与项目代码),下面的是一些微小的,事情得到的方式要注意(C#,Visual Studio中的MSBuild).

同样的项目方法

• 引用/外部库依赖:单元测试和模拟框架通常几乎没有依赖它,将它与实际项目所需的库相结合,列表增长非常快(没有人喜欢大型列表,对吧？)
• 命名冲突:命名类命名MyClass,常用方法是命名测试类MyClassTest- 这在使用导航/命名completition工具时会产生微小的烦恼(因为你有更多的机会可以选择多个结果进行快速导航)
• 无处不在的整体感觉

考虑到与类似功能相关的类通常共享前缀(例如ListManager......转换器,格式化程序,提供程序),命名冲突实际上会变得更加无聊.在易于理解的项目数量之间导航(通常为3-7)不是问题 - 输入测试,再次输入长列表.

分开的方法

• 项目编号:您必须计算两次生成的库的数量.一次是项目代码,另一次是测试.当涉及更大的项目(200-300 +子项目/库)时,测试项目的数量翻了一倍,以一种你永远不想体验的方式扩展IDE的启动时间

当然,现代机器将减轻项目数量问题.除非这确实成为一个问题,否则我总是采用分离的项目方法 - 它更整洁,更容易管理.