对于集成测试应该嘲笑什么？

Question

在阅读以测试为导向的面向对象的成长软件时,我了解了测试隔离和测试脆弱性.我们认为每个测试都应该对一段代码或功能非常具体,并且应该将测试代码覆盖的重叠保持在最低限度.隐含的理想是代码中的每个更改都应该导致只打破一个测试.避免花费时间经历多次破坏测试以确认一个更改是原因以及是否通过测试修改来修复.

现在这对于单元测试来说似乎很容易,但它们本质上是非常孤立的.但是,当通过集成测试呈现时,似乎很难避免多个测试执行相同的代码路径,特别是在单元测试之外运行时.

所以我的问题是,在进行集成测试时应该嘲笑哪些依赖项？有什么可以嘲笑的吗？是否应该测试单个执行路径,并且模拟与该代码路径不直接相关的所有副作用？

我正在考虑进行成对集成测试.测试两个对象之间的一个关系,并模拟其他一切.然后,除了通过成对形成完整的端到端测试链之外,其中任何一个对象中的更改对其他集成测试的影响应该最小.

感谢您的任何信息..

编辑:只是为了澄清,我基本上问"如何在正常的开发过程中避免大量失败的集成测试？".我假设是通过使用模拟来实现的,为什么我询问了要模拟的内容.

更新:我发现了一个关于JBRainsberger的集成测试的非常有趣的讨论,我认为这个答案相当好,如果可能有点争议的话.标题是"集成测试是一个骗局",所以你可以猜测,他根本不提倡集成测试(端到端类型测试).认为积分测试总是远远低于彻底测试可能的相互作用所需的量(由于组合爆炸),并且可能给出错误的信心.相反,他建议他称之为协作测试和合同测试.这是一个90分钟的谈话,不幸的是白板不是很清楚,没有代码示例,所以我仍然围绕它.当我有清楚的解释时,我会在这里写出来!除非别人打败我...

以下是合同测试的简要概述.听起来像契约类型断言,我相信可以/将在C++中以非虚拟接口模式实现.

http://thecodewhisperer.tumblr.com/post/1325859246/in-brief-contract-tests

集成测试是一个骗局视频讲座:http: //www.infoq.com/presentations/integration-tests-scam

摘要:

集成测试是一个骗局.您可能正在编写需要进行彻底测试的2-5%的集成测试.你可能在整个地方重复单元测试.您的集成测试可能会在整个地方相互重复.当集成测试失败时,谁知道什么坏了？了解解决问题的双管齐下的攻击:协作测试和合同测试.

Answer 1

对于集成测试，您应该模拟最少量的依赖项以使测试正常工作，但不能更少:-)

由于系统中组件的集成显然是您在集成测试期间要测试的内容，因此您应该尽可能使用真实的实现。但是，您显然想要模拟一些组件，因为您不希望集成测试开始向用户发送邮件。当您不模拟这些依赖项时，显然您模拟得太少了。

顺便说一句，这并不意味着您不应该允许集成测试发送邮件，但至少您希望将邮件组件替换为仅将邮件发送到某些内部测试邮箱的组件。