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

EN

是的，它们应该是分开的(文件夹，最好是项目)。一些原因：

• GREP.在生产源代码中搜索字符串更容易。
• 代码覆盖率。想象一下，尝试为coverage.
• Different标准指定要包含的文件。您可能只想在生产code.
• Simplified生成文件/构建脚本上运行静态分析等。

现代IDE将允许您处理来自不同项目/文件夹的代码，就好像它们是相邻的一样。

你能做的最糟糕的事情就是在同一个文件中包含测试和生产代码(使用条件编译，不同的入口点等)。这不仅会让试图阅读代码的开发人员感到困惑，而且还会冒着意外发布测试代码的风险。

由于我有机会使用这两种方法(独立的和项目代码)，这里有一些小东西需要注意(C#、Visual Studio、MsBuild)。

相同的项目方法

• References/external库依赖关系:单元测试和模拟框架本身通常只有很少的依赖关系，结合实际项目所需的库，列表增长非常快(而且没有人喜欢大的列表，对吧？)
• 命名冲突:将类命名为MyClass，常用的方法是将测试类命名为MyClassTest --这在使用导航/命名完成工具时会造成一些小麻烦(因为您有更多的机会从一个以上的结果中进行选择，以快速获得无处不在的混乱

的感觉

考虑到与类似功能相关的类通常如何共享前缀，命名冲突实际上会变得更加令人厌烦。ListManager ...转换器、格式化程序、提供程序)。在可理解的项数(通常为3-7个)之间导航不是问题--输入测试，再次输入长列表。

分离方法

• 项目编号:您必须将生成的库数量计算两次。一次仅用于项目代码，另一次用于测试。当涉及到更大的项目(200-300+子项目/库)时，如果测试项目的数量增加了一倍，则会以一种您永远不想遇到的方式延长启动时间

当然，现代机器将缓解项目数量问题。除非这真的成为一个问题，否则我会一直使用 go for separated projects的方法--它更整洁，更容易管理。

在完全自动化的构建和单元测试框架中，您基本上可以将它们分离出来。

在夜间构建完成后启动自动化的单元测试更有意义。将它们分开可以更容易进行维护。