我并不是指在集成测试通过之前推迟所有单元测试。我指的是那些验证SUT正确地与第三方神秘API交互的单元测试。
推迟这些单元测试的理由是他们验证了一些未知的东西。如果我不知道第三方神秘API如何工作，我怎么能写一个单元测试来确保SUT正确使用第三方API？只有在一些最小集成测试通过后，我才真正知道要验证的行为。
当然，所有其他单元测试都应该在SUT以通常的方式写入之前编写（红色，绿色，重构）。
答案 0 :(得分：0)
假设它是一个外部api，我认为你的测试可能不符合单元测试的条件。他们将进行集成测试。
如何编写模拟器来测试代码，然后在可以访问第三方API时编写适当的集成测试？此外，如果你是单元测试第三方的东西，那么一旦这些东西不可用你的构建就会失败，从长远来看这可能是个问题。
答案 1 :(得分：0)
几年后，我做了更多的单元测试，觉得我更了解这一点。单元测试擅长验证一段代码是否正确假设您正确理解如何使用伪造的API（模拟/存根）。但要正确伪造这些API，您必须首先了解它们的工作原理。因此，在阅读了这些API的文档之后，您可以通过进行概念验证来检查您的理解 - 即使这意味着在编写代码后手动测试代码 - 或者通过编写集成测试。一旦您对第三方API的理解不熟悉，您可以在单元测试中伪造它并再次关注TDD。
第三方API的包装是编写集成测试的绝佳选择，您只需在不伪造第三方API的情况下测试最小包装，以确保正确理解它。其中一些测试可能不是真正的测试，而是像测试一样编写的演示。它们也会在以后派上用场，因为如果您忘记了某些工作原理，可以查看它们，帮助同事了解API，并在升级API时发现微妙的重大变化。
今天，我经常编写包装器的集成测试，编写演示/第三方API的示例，以及与我的情况相关的角点案例，甚至编写生产代码并在必要时手动测试它。我只需要在我使用的API中存在含糊不清或不明确的情况。一旦我对如何使用它充满信心，那么＃＆＃34;正常＆＃34; TDD。