集成测试/单元测试：做太多集成测试？答案

【问题标题】：Integration tests/unit tests: Doing too many integration tests?集成测试/单元测试：做太多集成测试？
【发布时间】：2013-07-04 15:19:08
【问题描述】：

我一直在设计一些单元测试来模拟每个单元所具有的每个依赖项。这按预期工作。我现在需要进行集成测试。

例如，我有 1 个层依赖于 2 个附加层，我已经分别测试了每个单独的层作为一个单元来模拟每个依赖项，但我现在需要执行集成测试。

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

  Layer1 > Layer2 > Layer3

我可以在 Layer1 上进行集成测试，该测试将为 Layer2 和 Layer3 提供真实实例（而不是模拟）。

那么我应该对 Layer2 进行集成测试吗？其中包括以下工作流程

  Layer2 > Layer3

这里没有任何东西是模拟出来的，它们是集成测试。

我看到的问题是我的 Layer1 集成测试确实涵盖了 Layer2 的相同集成测试。

我不太确定我是否太过分了。我知道最好有更多的测试而不是不够，但我在测试 layer1 时看到重复

  Layer1 > Layer2 > Layer3

和第二层

  Layer2 > Layer3

所以我可能只测试 Layer1 - 使用集成测试

  Layer1 > Layer2 > Layer3

可能会涵盖 layer2 和 layer3 的集成测试

  Layer2 > Layer3

【问题讨论】：

标签： unit-testing mocking tdd integration-testing

【解决方案1】：

您应该测试应用程序中可实现的任何场景（通过客户/组件交互）。如果Layer2 可以在没有Layer1 干扰的情况下与Layer3 交互 - 测试一下。

将集成测试视为对整个用例的测试。是否存在您的客户可以通过单独调用Layer2 开始的情况？如果有，请测试它。如果不是，你为什么要这样做？永远不要测试不使用的东西。这与编写“稍后有人可能需要”的代码相同。浪费时间，别这样。

【讨论】：

+1 这是一个很好的经验法则。然而，值得补充的是，如果您觉得应用程序中的某些地方可以从将集成测试集中在一对特定组件中受益，那么不要害怕这样做。在处理两个组件使用不寻常的格式或协议交换数据的遗留应用程序时，我经常会遇到这种情况，并且围绕这些组件进行一组特定的集成测试可以提供额外的有价值的安全网。

【解决方案2】：

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

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

在您的示例中，如果您在 Layer1 上进行了一个集成测试，该测试涉及所有三层，那么这充分涵盖了您的场景。正如前面的回答中提到的，没有必要故意测试Layer2 > Layer3，除非你说其他东西可能会击中Layer2并完全绕过Layer1。但即使是这样，我也会从“其他东西”开始准备一个集成测试。仅当您的用例从 Layer2 开始时才测试 Layer2 > Layer3。

【讨论】：

【解决方案3】：

集成测试有时很有用，但在性能和复杂性方面它们达到了high cost。

IMO 不应将它们用于对系统行为的详尽验证，它们包含的移动部件的数量以及它们的行为组合的数量通常太高了。

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

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

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

【讨论】：