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

Question

让我从定义开始:

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

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

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

我想请求开发社区分享他们为什么自动集成测试无法取代经典单元测试的意见.

以下是我自己的观察:

1. 集成测试不能与TDD方法一起使用
2. 集成测试很慢,无法经常执行
3. 在大多数情况下,集成测试并不表明问题的根源
4. 使用集成测试创建测试环境更加困难
5. 确保高覆盖率(例如模拟特殊情况,意外故障等)更加困难
6. 集成测试不能与基于交互的测试一起使用
7. 集成测试进一步发现缺陷的时刻(来自paxdiablo)

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

谢谢,安德烈

Answer 1

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

直接解决您的主题:集成测试不是问题,不是问题.使用它们代替单元测试是.

Answer 2

已经有研究^(a)表明,当你离开引入错误的点时,修复错误的成本会变得更高.

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

相比之下,当客户(或所有客户)发现问题时,修复的成本是多少.许多人都参与进来,新软件必须匆忙建成并推向现场.

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

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

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

^(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,真的在更传统的意义上做"测试".