集成测试/单元测试：做太多的集成测试了吗？

Question

我一直在设计许多单元测试，模拟每个单元所依赖的组件。这个方法达到了预期的效果。现在我需要进行集成测试。

例如，我有一个层依赖于另外两个层，我已经分别对每个单独的层进行了单元测试，并模拟了每个依赖关系，但现在我需要进行集成测试。

所以想象一下，我有以下三个层...

  Layer1 > Layer2 > Layer3

我可以在第一层进行集成测试，并使用实际实例（而不是模拟实例）来测试第二层和第三层。

那么我是否应该为第二层进行集成测试？包含以下工作流程。

  Layer2 > Layer3

这里没有任何模拟，它们都是集成测试。

我所看到的问题是，我的第一层的集成测试实际上涵盖了第二层的相同集成测试。

我不太确定是否有点过头了。我知道有更多的测试比没有足够的测试要好，但是在测试第一层时，我看到了重复的内容。

  Layer1 > Layer2 > Layer3

和第二层

  Layer2 > Layer3

所以，我可能只需要使用集成测试来测试Layer1。

  Layer1 > Layer2 > Layer3

这可能涵盖第二层和第三层的集成测试。

  Layer2 > Layer3 

- Martin

Answer 1

你应该测试你的应用程序可以实现的任何场景（通过客户/组件交互）。如果 Layer2 可以与 Layer3 交互而不受 Layer1 的干扰 - 进行测试。

将集成测试视为整个用例的测试。您的客户是否可以通过仅调用 Layer2 来开始某个情况？如果有，就进行测试。如果没有，为什么要这样做呢？永远不要测试不被使用的东西。这与编写"以后可能会用到的代码"相同。这是浪费时间，请不要这样做。

- k.m

---

+1 这是一个很好的经验法则。然而，值得补充的是，如果你觉得在应用程序中有某些地方可以从专注于特定一对组件的集成测试中受益，那就别害怕去做。当我在处理遗留应用程序时，两个组件使用不寻常的格式或协议交换数据，这种情况经常发生，拥有一组特定的集成测试可以为这些组件提供额外的安全保障。 - robjohncox

Answer 2

我倾向于宽泛地定义集成测试。如果我看到一个涵盖了几个类之间交互的测试，我倾向于称其为集成测试（还有另一个术语，但我现在想不起来了）。对我来说，这不仅仅是关于层面的整合。

重点是，你应该根据关键场景和/或重要用例进行集成测试。从这些事情中，你将知道你的集成测试应该从哪里开始。不要为了创建而创建集成测试。当用于不太重要的部分时，它们往往会带来过多的工作量和维护。

在你的例子中，如果你有一个针对Layer1的集成测试，它覆盖了所有三个层，则足以满足你的场景需求。如早期答案所述，除非你正在说其他东西可能会完全跳过Layer1并击中Layer2 > Layer3，否则没有必要故意测试Layer2 > Layer3。但即使是这种情况，我也会从那个"其他东西"开始准备一个集成测试。只有当你有一个从Layer2开始的用例时才测试Layer2 > Layer3。

- aberrant80

Answer 3

集成测试有时很有用，但从性能和复杂度方面来看，它们的成本很高。

我认为它们不应该用于系统行为的彻底验证，因为它们涉及的移动部件数量和它们行为的组合数量通常太多了。

我主要进行两个目的的集成测试：

• 在项目开始阶段，端到端测试是你应该编写的第一批测试，如果你想建立一个Walking Skeleton，它代表你的系统的一个简单完全功能的第一个片段。

• 测试系统与第三方代码之间的集成。或者更准确地说，测试您编写的适配器是否正确调用了这些第三方模块，以隔离您的系统与第三方模块之间的关系。

如果您正在努力理解所有不同的测试实践以及何时使用它们，那么书籍 "Growing Object-Oriented Software, Guided by Tests" 包含非常有用的指南。

- guillaume31