阅读《Growing Object Orientated Software Guided by Tests》后，我了解了测试隔离和测试脆弱性。每个测试都应该非常具体地针对一段代码或功能，测试覆盖的代码重叠部分应该尽量减少。暗示理想情况是代码中的每个更改都应只导致一个测试失败。避免花费时间去检查多个失败的测试以确认一个更改是否是原因，并且测试修改是否修复它。
现在，对于单元测试来说，这似乎很容易，它们的本质非常隔离。但是，在集成测试中，似乎很难避免多个测试使用相同的代码路径，特别是当与单元测试一起运行时。
因此，我的问题是，在进行集成测试时应模拟哪些依赖项？是否需要模拟任何内容？是否应该测试单个执行路径，并模拟所有与此代码路径无直接关联的副作用？
我正在玩弄使用成对集成测试的想法。测试两个对象之间的一个关系，并模拟其他所有内容。然后，这些对象中的任何一个发生更改时，对其他集成测试的影响应最小化，并通过成对形成完整的端到端测试链。
谢谢任何信息。 编辑：只是为了澄清，我基本上是在问“如何避免在开发过程中出现大量失败的集成测试？”。我认为这可以通过使用模拟来实现，这就是我询问应该模拟什么的原因。
现在，对于单元测试来说，这似乎很容易，它们的本质非常隔离。但是，在集成测试中，似乎很难避免多个测试使用相同的代码路径，特别是当与单元测试一起运行时。
因此，我的问题是，在进行集成测试时应模拟哪些依赖项？是否需要模拟任何内容？是否应该测试单个执行路径，并模拟所有与此代码路径无直接关联的副作用？
我正在玩弄使用成对集成测试的想法。测试两个对象之间的一个关系，并模拟其他所有内容。然后，这些对象中的任何一个发生更改时，对其他集成测试的影响应最小化，并通过成对形成完整的端到端测试链。
谢谢任何信息。 编辑：只是为了澄清，我基本上是在问“如何避免在开发过程中出现大量失败的集成测试？”。我认为这可以通过使用模拟来实现，这就是我询问应该模拟什么的原因。
更新：我找到了一场非常有趣的由J.B.Rainsberger主讲的关于集成测试的演讲，我认为这个演讲对此有很好的回答，尽管也有点争议性。它的标题是“集成测试是一个骗局”，所以你可以猜到，他根本不提倡集成测试（端到端类型的测试）。他的观点是集成测试总是远远低于彻底测试可能的交互作用所需的数量（由于组合爆炸），并且可能会给人一种虚假的信心。 相反，他推荐了他称之为协作测试和契约测试。这是一个90分钟的演讲，不幸的是白板不是很清晰，也没有代码示例，所以我还在理解中。当我有一个清晰的解释时，我会在这里写下来！除非有人比我先写了..
这里是契约测试的简要概述。听起来像是设计契约类型的断言，我认为这可以在C++中通过实现非虚拟接口模式来实现。
http://thecodewhisperer.tumblr.com/post/1325859246/in-brief-contract-tests
《集成测试是骗局》视频演讲： http://www.infoq.com/presentations/integration-tests-scam
摘要：
集成测试是一种骗局。你可能只编写了需要全面测试的2-5％的集成测试。你可能在各个地方重复编写单元测试。你的集成测试可能在各个地方重复彼此。当集成测试失败时，谁知道哪里出了问题？学习解决问题的双管齐下方法：协作测试和契约测试。