从单元测试到集成测试的有效转换

Question

我目前正在调查我们应该如何在即将推出的项目中执行测试。为了在开发过程早期发现错误，开发人员将在实际代码（TDDish）之前编写单元测试。单元测试将集中在单元上（这种情况下的一种方法），因此依赖性会被嘲弄等等。

现在，我还想在与其他单元交互时测试这些单元因为单元测试已经写好了，所以我认为应该有一个有效的最佳做法来做到这一点。我的想法是，单元测试将被重用，但被嘲弄的对象将被删除并替换为真实的对象。我现在不同的想法是：

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

我看到这些方法的所有方法都有优点和缺点。哪些是首选的，为什么？是否有更好的方式从单元测试有效地转换到集成测试？或者这通常以其他方式完成？

Answer 1

我同意绝大多数其他答案，即unittesting应单独从集成测试（选项3）。

但我不同意你的禁忌参数：

[...]这（从分隔条件集成测试单元），但是将 需要大量的冗余代码和维护测试案例会工作的两倍。

生成测试数据的对象可以是一个大量的工作，但这是可以重构测试辅助clases又名ObjectMother可以从 单元测试和集成测试中使用，所以没有必要冗余有

在单元测试中，您可以检查受测试的类的不同条件。

对于集成测试，不需要重新检查这些特殊情况。 而是检查组件是否一起工作。

例

您可能有单元测试对于其中将引发异常4种不同的情况。 对于集成，不需要重新测试所有4个条件 一个与异常相关的集成测试足以验证集成系统可以处理异常。

Answer 2

像Ninject/Autofac/StructureMap这样的IoC容器可能对您有用。单元测试可以通过容器来解析被测系统，注册是否有嘲笑或真实对象只是注册的问题。与您的工厂方法类似，但IoC容器是工厂。新开发人员需要一点培训才能理解，但任何复杂系统都是如此。这样做的缺点是注册情况可能会变得相当复杂，但是对于任何给定的系统来说，难以说是否太而没有尝试它。我怀疑这是你没有找到任何似乎确定的答案的原因。

Answer 3

我会去的第三个选项

• 单独从不同 类的单元测试的集成测试。然而这将需要大量的冗余代码，并且保持测试用例将是工作的两倍。

这是因为单元测试和集成测试有不同的目的。单元测试表明单独的一项功能是孤立的。集成测试表明，不同的功能块在彼此交互时仍然有效。

因此，对于单元测试，您希望嘲笑事物，以便您只测试一项功能。

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

我会让他们在单独的项目中。在我的地方运行良好的是使用NUnit和Moq进行单元测试项目。这是写入代码时写入的TDD。集成测试是Specflow/Selenium，功能文件是在产品负责人的帮助下编写的，因此我们可以验证我们是否提供了所有者想要的东西。

这确实会在短期内创造额外的工作量，但会导致更少的错误，更轻松的维护和交付匹配要求。

Answer 4

集成测试应该与您的单元测试不同的类，因为您正在测试不同的行为。我认为集成测试的方式是，它们是您在确保一切协同工作时执行的方法。他们会将输入用于应用程序的某些部分，并确保返回预期的输出。

Answer 5

我认为你搞乱了单元测试和集成测试的目的。 单元测试用于测试单个类 - 这是低级API。集成测试正在测试班级如何合作。这是另一个更高级别的API。 通常，您不能在集成测试中重用单元测试，因为它们表示不同级别的系统视图。 使用spring context可能有助于设置集成测试的环境。

Answer 6

我不确定重复使用单元测试与真实对象而不是嘲笑是实施集成测试的正确方法。

单元测试的目的是验证从外部世界隔离的对象的基本正确性。嘲笑在那里确保隔离。如果你用真正的实现替代它们，你实际上最终会测试完全不同的东西 - 大部分同一链对象的正确性，并且你多次重复测试它。

通过使集成测试不同于单元测试，您将能够选择要验证的系统部分 - 通常，测试意味着配置，I/O，与第三方的交互的部分是个好主意第三方系统，用户界面或其他任何单元测试都很难涵盖的内容。