关于采用由外向内方法的 TDD，有一个问题我找不到答案：
我实现了一个新单元 (A)，为它编写了一个测试，这个单元需要一个尚不存在的依赖项 (B)。在我的测试中，很容易模拟这种依赖关系，但我在生产代码中应该做什么？
我是否首先实现 (B) 并让 (A) 的测试同时失败，因为我还没有继续实现它以使其测试通过？
或者我是先完成（A），同时让（B）的测试失败，因为它例如只是返回“空”对象，而不是实际执行规范要求的操作？
或者我应该让 (B) 的测试在我继续实现 (A) 的同时暂时检查它是否返回“空”对象 - 尽管这实际上不是 (B) 的规范吗？
【问题讨论】：
标签： unit-testing testing language-agnostic mocking tdd
TDD 的基本策略是让您的所有测试都通过，除了您现在正在处理的测试。在您担心 (B) 之前让 (A) 的测试通过。
您为类 (A) 及其复杂的依赖项 (B) 编写测试和代码的顺序是
此时，您可以选择在 (A) 或 (B) 上多做一些工作，或者开始新的工作。
尽管这种策略可以让您的测试始终通过，但它并不能确保您的应用程序立即执行一些有用的操作。确保您的应用程序最终做一些有用的事情的方法超越了 TDD：首先编写一个验收测试（它在没有模拟的情况下针对整个应用程序运行）和 TDD，直到验收测试和您的单元测试全部通过。 （更多信息请参见bdd。）
验收测试（或其他集成测试）还确保您在模拟类的测试和代码中正确复制模拟。
还请注意，跟踪您已经想到但尚未实现的需求，或者您仅在模拟中“实现”并且需要在模拟依赖项的测试和代码中实现的需求至关重要。这就是为什么TDD By Example 和其他如何完成 TDD 的示例如此多地谈论实际或心理的待办事项列表。对于具有模拟依赖项 (B) 的类 (A)，在编写模拟之后，您可以返回处理 (A) 或在 (B) 中实现刚刚对模拟所做的工作。无论哪种方式，您都必须跟踪您选择不做的事情，直到您准备好回去做。
【讨论】：
我建议仅在您的代码中确实需要 B 时才依赖 B。如果 A 中没有任何东西依赖于 B，为什么要在这个阶段添加它？
如果你的代码现在真的需要 B，为什么不开始实现你现在需要的 B 的功能呢？
当然，如果 B 没有任何逻辑，您也可以在代码中使用虚拟对象而不是 B。否则我会开始实施 B.
【讨论】：