最佳实践：单元测试结构

Question

我有点困惑。得到了不同组件中的单元测试所涵盖的项目。合作开发者也创建了另一个项目+另一个单元测试程序集。现在我们想在两个单元测试项目（对象工厂，一些初始化任务，注入/模拟助手等）之间混合一些逻辑。这将导致他的项目引用我的用途。

我找到了一个视点，代表所有项目的1个单元测试组件（有时2个，其中第2个包含集成测试）。这是正确的方法吗？如果不是 - 在哪里放置单元测试的共享逻辑？

Answer 1

肯定有不同的方法，没有单一的“正确方法”。这就是我们构建测试的方式：

我们的产品中有“模块”，包含多个组件。对于每个“模块”，我们有一个单独的单元测试组件和一个单独的集成测试组件。我们以这种方式引用其他人的测试程序集：

• “核心”单元测试不引用任何内容。它还包含单元测试的辅助类。
• “核心”集成测试参考“核心”单元测试。它包含其他集成测试助手类（例如数据库内容）
• “模块X”单元测试参考“核心”单元测试
• “模块X”集成测试可以引用“模块X”单元测试和“核心”测试

“模块X”测试当然从不参考“模块Y”测试。

Answer 2

为什么要将单元测试放在单独的程序集中的理由是防止将测试代码与生产代码混淆。程序集提供了一个清晰的关注点，使其足够灵活，可以在不需要时删除测试。例如。当您发布时，最终客户在他/她只想使用最终结果时对下载所有测试代码不感兴趣。

关于拥有许多测试组件（每个“实际代码”组件一个）是一个理智的想法。在测试程序集之间添加引用并不困难，实际上可以帮助您避免过多地混淆代码，因为您不希望程序集之间有很多引用（即依赖项）。

另外，不要尝试为单元测试使用太多的共享逻辑，因为这是单元测试/模拟/ DI框架的用途！在测试代​​码中有许多自定义实现的工厂，这是一个很好的指标，表明您使生产代码过于复杂，无法满足需要。