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

让我从定义开始：

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

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

虽然他们经常服务于不同的目的，但这些术语经常混在一起。开发者将自动化集成测试称为单元测试。也有人认为哪一个更好，在我看来是一个错误的问题。

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

这里是我自己的观察：

>集成测试不能与TDD方法一起使用
>集成测试速度慢，不能经常执行
>在大多数情况下，集成测试不会指出问题的根源
>使用集成测试创建测试环境更加困难
>更难以确保高覆盖(例如模拟特殊情况，意外故障等)
>集成测试不能与Interaction based testing一起使用
> Integration tests move moment of discovering defect further(自paxdiablo起)

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

谢谢，
安德烈

已经有研究(a)表明，修复bug的成本随着从引入bug的点移开而变得更高。

例如，在软件中修复一个错误通常需要花费很少的时间，你甚至还没有向上推动源代码控制。这是你的时间，而不是很多，我保证(假设你对你的工作有好处)。

与客户(或所有客户)发现问题需要花费多少费用进行对比。许多级别的人参与，新软件必须匆忙建立并推出到现场。

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

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

>我们的单元测试也是自动的，除了初始设置，运行它们的成本很小。
>它们形成集成测试的开始。所有单元测试都在集成阶段重新运行，以检查集成本身是否没有破坏任何东西，然后还有集成团队添加的额外测试。

(a)例如参见http://slideshare.net/Vamsipothuri/defect-prevention，幻灯片#5，或在网上搜索缺陷预防：降低成本和提高质量。

原文地址：https://www.jb51.cc/javaschema/282429.html