为什么使用集成测试而不是单元测试是一个坏主意？

Question

让我从定义开始：

单元测试是一种软件验证和验证方法，程序员可以测试各个源代码单元是否适合使用

集成测试是软件测试的活动，其中各个软件模块作为一个组合并进行测试。

尽管它们经常用于不同的目的但这些术语是混杂的。开发人员将自动集成测试称为单元测试。还有人认为哪一个更好，在我看来这根本就是一个错误的问题。

我想请求开发社区分享他们对自动集成测试无法取代经典单元测试的看法。

以下是我自己的观察：

1. 集成测试不能与TDD方法一起使用
2. 集成测试很慢，无法经常执行
3. 在大多数情况下，集成测试并不表明问题的根源
4. 使用集成测试创建测试环境更加困难
5. 确保高覆盖率（例如模拟特殊情况，意外故障等）更加困难
6. 集成测试不能与Interaction based testing
一起使用
7. Integration tests move moment of discovering defect further（来自paxdiablo）

编辑：再次澄清一下：问题不在于是否使用集成或单元测试，而是关于哪一个更有用。基本上我想收集开发团队的参数，这些团队只编写集成测试并将它们视为单元测试。 涉及来自不同层的组件的任何测试都被视为集成测试。这是与单元测试相比较，其中隔离是主要目标。

谢谢你， 安德烈

Answer 1

集成测试会告诉您它是否正常工作。单元测试告诉你什么不起作用。只要一切正常，你就“不需要”单元测试 - 但是一旦出现问题，将单元测试点直接解决问题是非常好的。如你所说，它们有不同的用途;两者都很好。

直接解决您的问题：集成测试不是问题，不是问题。使用它们而不是单元测试是。

Answer 2

已经有研究^（a）表明，当你离开引入bug时，修复bug的成本会更高。

例如，通常会花费相对较少的时间来修复您尚未推送到源代码控制的软件中的错误。这是你的时间，而不是很多，我保证（假设你对你的工作有任何好处）。

与客户（或所有客户）发现问题时的修复成本进行对比。许多人都参与其中，新软件必须匆忙建立并推向现场。

这是极端的比较。但即使单元测试和集成测试之间的差异也很明显。单元测试失败的代码主要只影响单个开发人员（当然，除非其他开发人员/测试人员等等）。但是，一旦您的代码参与集成测试，缺陷就会开始阻碍团队中的其他人员。

我们不会梦想用集成测试替换我们的单元测试，因为：

• 我们的单元测试也是自动化的，因此除了初始设置之外，运行它们的成本很低。
• 它们构成了集成测试的开始。所有单元测试都在集成阶段重新运行，以检查集成本身是否已破坏任何内容，然后集成团队已添加了额外的测试。

---

^（a）例如，请参阅http://slideshare.net/Vamsipothuri/defect-prevention，幻灯片＃5，或在网上搜索Defect prevention : Reducing costs and enhancing quality。

Answer 3

我发现集成测试明显优于单元测试。如果我对我的代码进行单元测试，那么我只测试它的作用与我对它应该做什么的理解。这只会捕获实现错误。但通常更大的问题是理解错误。集成测试同时兼顾。

此外，还存在巨大的成本差异;如果你正在大量使用单元测试，那么他们将所有其他代码放在一起的情况并不罕见。它们需要维护，就像代码的其余部分一样。集成测试的成本要低得多 - 在大多数情况下，无论如何都需要它们。

在极少数情况下，可能需要使用单元测试，例如对于内部错误处理路径，如果系统的其余部分正常工作，则无法触发，但大多数情况下，集成测试本身可以以更低的成本提供更好的结果。

Answer 4

在许多情况下，你需要两者。就我使用集成测试作为单元测试而言，您的观察是正确的，但它们并不意味着集成测试没有价值或需要，只是它们服务于不同的目的。人们可以同样认为单元测试不能取代集成测试，正是因为它们消除了对象之间的依赖关系，并且它们没有运用真实的环境。两者都是正确的。

Answer 5

• 集成测试很慢。
• 集成测试可能会有所不同 原因（它没有集中精力和 隔离的）。因此你需要更多 调试失败。
• 组合 场景对于整合来说很重要 未经单元测试时进行测试。

大多数情况下，我进行单元测试，并且集成测试（配置，查询）减少10倍。

Answer 6

这都是为了减少迭代时间。

使用单元测试，您可以编写一行代码并在一分钟左右验证它。通过集成测试，通常需要更长的时间（随着项目的增长，成本也会增加）。

两者都非常有用，因为它们都会检测到对方无法检测到的问题。

OTOH，来自“纯粹的”TDD方法，单元测试不是测试，它们是功能规范。整合测试，OTOH，确实在更传统的意义上进行“测试”。

Answer 7

两种类型的测试是不同的。在我看来，单元测试不是集成测试的替代方案。主要是因为集成测试通常是特定于上下文的。您可能会遇到单元测试失败而您的集成没有的情况，反之亦然。如果在使用许多其他组件的类中实现不正确的业务逻辑，您可能希望集成测试突出显示这些，您的单元测试对此无动于衷。我理解集成测试快速而简单。我认为，每次对代码库进行更改时，您都依赖于单元测试，并且使用绿色列表可以让您更加确信您没有在单个类级别中破坏任何预期的行为。单元测试为您提供针对单个类的测试，正在执行它的设计目标。集成测试测试多个一起工作的类执行您希望它们为该特定协作实例执行的操作。这就是OO开发的整个想法：封装特定逻辑的单个类，允许重用。

Answer 8

集成测试通常在单元测试后进行。我不确定在测试尚未经过测试的单元之间的交互中有什么价值。

如果齿轮可能损坏，测试机器齿轮如何转动是没有意义的。

Answer 9

我认为报道是主要问题。

特定小组件（如方法或最多类）的单元测试应该在每个法律场景中测试该组件（当然，一个抽象等价类但应覆盖每个主要组件）。因此，此时应该发现违反既定规范的变更。

在大多数情况下，集成仅使用每个子单元的可能方案的子集，因此故障单元仍然可以生成最初集成良好的程序。

由于您在下面指定的所有原因，通常很难在集成测试中实现最大覆盖率。如果没有单元测试，更有可能的是，在新的方案中对基本上运行它的单元的更改将不会被捕获，并且可能在集成测试中被遗漏。即使没有错过，也很难确定问题所在。

我不确定大多数开发人员将单元测试称为集成测试。我的印象是，大多数开发人员都了解这些差异，这并不意味着他们也会这样做。

Answer 10

编写单元测试来测试类的方法。如果该类依赖于任何类型的外部资源或行为，您应该模拟它们，以确保您只测试您的单个类。单元测试中不应有外部资源。

集成测试是更高级别的粒度，如您所述，您应该测试多个组件以检查它们是否按预期一起工作。对于大多数项目，您需要集成测试和单元测试。但重要的是将它们分开并理解差异。

在我看来，单元测试对于人们来说更难以掌握。它需要对OO原则有很好的了解（基本上是基于一级一级的责任）。如果您能够单独测试所有类，那么您很可能拥有一个可维护，灵活且可扩展的良好设计解决方案。

• 当你办理登机手续时，你的构建服务器应该只运行单元测试 它们应该在几秒钟内完成，而不是几分钟或几小时。
• 集成测试应该在一夜之间或根据需要手动运行。

Answer 11

• 单元测试专注于测试单个组件，而不依赖于外部依赖项。它们通常用于模拟或存根。
• 集成测试涉及多个组件，可能依赖于外部依赖。

我认为两者都很有价值，在他们的工作中，任何一方都无法取代另一方。我确实看到很多集成测试伪装成单元测试，虽然有依赖性并且需要很长时间才能运行。它们应该单独运行，并作为持续集成系统的一部分。

集成测试通常会发现单元测试不会发生的事情......

Answer 12

通过集成测试，您可以检查应用程序的整个用例。

单元测试检查应用程序中的低级逻辑是否正确。

集成测试对于管理者来说对于项目状态更安全更有用（但对开发人员也很有用！）。

单元测试对于编写和更改应用程序逻辑的开发人员更有用。

当然，使用它们来达到最佳效果。

Answer 13

我如何看待集成测试和单元测试：

单元测试：使用低级详细信息隔离测试小事物，包括但不限于“方法条件”，检查，循环，默认设置，计算等。

集成测试：测试更广泛的范围，其中涉及许多组件，这些组件在结合在一起时会影响其他事物的行为。集成测试应涵盖端到端的集成和行为。集成测试的目的应该是证明系统/组件在集成在一起时可以正常工作。

Answer 14

“使用集成测试 而不是 单元测试”是一个坏主意，因为这意味着您不了解它们正在测试不同的东西，当然通过和失败的测试将为您提供不同的信息。当他们从任一侧接近时，它们就构成了测试的阴阳。

• 集成测试采用一种模拟用户如何与应用程序交互的方法。这些将减少对大量手动测试的需求，并且通过测试可以告诉您，您的应用程序可以在多个平台上运行很好。测试失败会告诉您某些东西已损坏，但通常无法为您提供有关底层代码有什么问题的大量信息。

• 单元测试应着重于确保函数的输入和输出在所有情况下都是期望的。通过单元测试可能意味着您的功能正在按照规范运行（假设您已针对所有情况进行了测试）。但是，所有功能在隔离状态下正常工作并不一定意味着部署后一切都会正常运行。失败的单元测试将为您提供有关失败原因的详细详细信息，从理论上讲应该使调试更容易。

最后，我相信单元测试和集成测试的结合将产生最快，最无缺陷的软件。您可以选择使用一个而不是另一个，但是我避免使用短语“代替”。