我正在试验测试驱动的开发，发现经常遇到以下情况：

1. 我为某些功能X编写测试。这些测试失败。
2. 在尝试实现X时，我看到我需要在代码的下层实现某些功能Y。所以...
3. 我为Y编写测试。现在针对X和Y的测试均失败。

一旦我同时处理了不同代码层中的4个功能，我就失去了对实际工作的关注（太多的测试同时失败）。

我认为即使在开始编写测试之前，也可以通过更加努力地计划任务来解决此问题。但是在某些情况下，我不知道需要更深入地研究，因为例如，我不太了解底层API。

在这种情况下我该怎么办？TDD有什么建议吗？

好消息是您意识到被测代码需要帮助。与其立即实施，不如创建一个接口并使用模拟来确保您的测试正确输入了代码。通过这些测试后，您可以继续执行其依赖的代码。

存根和模拟可用于模拟尚未修改/实现的功能。它们还可以帮助您解决导致这种“链式反应”的依赖性。

另一方面，最好只进行一次（失败）测试以驱动下一个更改。

可以暂时禁用其他针对依赖新功能的代码的测试，因为它们在此时并没有真正的意义。在您的情况下，请禁用X的测试，直到实现Y等。

我认为这样一来，您就可以只专注于您想要的下一个更改。

停止

临时看来，这里可能存在两个独立的问题：

1. 您忘记了一些故事和测试场景，直到开始处理特定的测试场景时才发现它们，和/或

2. 您实际上是在进行单元测试，而不是TDD 功能测试

对于＃1，请停止，返回并更新故事和测试方案，然后从其他方案重新开始。

对于＃2，请停止，并记住您正在测试功能而不是单元，因此请使用模拟掩盖其他接口和/或实施更多代码以使测试通过而不添加新的测试方案。假定您没有丢失测试场景，而是（实际上很常见）混合单元测试和TDD。

对于TDD和我来说，这是一个很大的问题，对我来说是巨大的挫败感。我感觉在这种情况下TDD缺乏，您无法在开始开发之前就不知道需要哪些较低级别的组件或功能。

我个人发现，TDD仅在您完全知道执行某项功能所需的内容以及调用该功能所需的内容后才能起作用。开发人员在开始之前并不总是了解所有内容，因此我发现减轻自己所描述情况的最佳方法是：

原型

当我制作简单的原型应用程序以探索和发现技术问题的方法时，我会发现很多相关工作，并在开始之前就将这些研究排除在外。设计和估算也变得容易得多。

如果原型必须涉及到它成为应用程序，那么我敦促您不要懒惰，而是在事后为原型构建单元测试。

届时，您应该对低级API有所了解，并能够在高级别组件中成功模拟低级API。

这取决于您在进行TDD时进行何种测试。

经典模型是编写单元测试，并使用模拟或存根将测试与其他“单元”代码分离。

还有许多其他替代模型，例如ATDD，可以在其中测试全栈或几乎全栈测试。在这种特殊情况下，您的编写测试可以断言所需的程序行为，而不是单个代码单元，因此您不会编写其他测试。您将获得工具往返来满足测试。然后，您为其他功能/行为添加其他测试。