c# - 从单元测试到集成测试的有效过渡

Question

我目前正在调查我们应该如何在即将进行的项目中执行测试。为了在开发过程中及早发现错误，开发人员将在实际代码 (TDDish) 之前编写单元测试。单元测试将像它们应该的那样，孤立地关注单元(在这种情况下是一种方法)，因此依赖关系将被模拟等。

现在，我还想在这些单元与其他单元交互时对其进行测试，并且我认为应该有一个有效的最佳实践来执行此操作，因为已经编写了单元测试。我的想法是单元测试将被重用，但模拟对象将被删除并替换为真实对象。我现在的不同想法是:

• 在每个测试类中使用一个全局标志来决定是否应该使用模拟对象。这种方法需要多个 if 语句
• 使用创建“instanceWithMocks”或“instanceWithoutMocks”的工厂类。这种方法对于新开发人员使用起来可能很麻烦，并且需要一些额外的类
• 将集成测试与不同类中的单元测试分开。然而，这将需要大量冗余代码，并且维护测试用例将是工作量的两倍

在我看来，所有这些方法都各有利弊。其中哪一个是首选，为什么？是否有更好的方法可以有效地从单元测试过渡到集成测试？还是通常以其他方式完成？

Answer 1

我会选择第三种选择

• 将集成测试与单元测试分开 类。然而，这将需要大量冗余代码和 维护测试用例将是工作的两倍

这是因为单元测试和集成测试的目的不同。单元测试表明一个单独的功能 block 是独立工作的。集成测试表明，不同的功能部分在相互交互时仍然有效。

因此，对于单元测试，您需要模拟一些东西，以便您只测试一个功能。

对于尽可能少的集成测试模拟。

我会将它们放在不同的项目中。在我这里行之有效的是有一个使用 NUnit 和 Moq 的单元测试项目。这是编写代码时编写的 TDD。集成测试是 Specflow/Selenium，功能文件是在产品所有者的帮助下在规划 session 中编写的，因此我们可以验证我们是否交付了所有者想要的东西。

这确实会在短期内产生额外的工作，但会导致错误减少、维护更容易以及满足交付匹配要求。