TDD方法可以自上而下应用吗？

我不清楚TDD（该方法论）如何处理以下情况。假设我想在Python中实现mergesort算法。我首先写

assert mergesort([]) === []

并且测试失败

NameError：未定义名称“ mergesort”

然后我添加

def mergesort(a):
    return []

我的测试通过了。接下来我添加

assert mergesort[5] == 5

我的测试失败了

断言错误

我通过

def mergesort(a):
    if not a:
        return []
    else:
        return a

接下来，我添加

assert mergesort([10, 30, 20]) == [10, 20, 30]

现在我必须尝试通过此步骤。我“知道” mergesort算法，所以我这样写：

def mergesort(a):
    if not a:
        return []
    else:
        left, right = a[:len(a)//2], a[len(a)//2:]
        return merge(mergesort(left)), mergesort(right))

这失败了

NameError：未定义名称“合并”

现在是问题。如何开始merge使用TDD 并开始实施？看来我做不到，因为我没有完成“挂起”的测试mergesort，未通过，直到merge完成，测试才能通过！如果此测试仍然存在，我将永远无法真正做到TDD，因为在TDD迭代构建过程中我不会变得“绿色” merge。

似乎我陷入了以下三个丑陋的场景，想知道（1）TDD社区更喜欢其中哪一个，或者（2）我还缺少另一种方法？我看过鲍勃叔叔TDD演练的几本，并且不记得以前看到过这样的情况！

这是3种情况：

1. 在具有不同测试套件的不同目录中实现合并。
2. 开发辅助功能时，不必担心绿色，只需手动跟踪您真正要通过的测试即可。
3. 注释掉（GASP！）或删除该mergesort调用中的行merge；然后开始merge工作后，将它们放回去。

这些对我来说都是愚蠢的（或者我看错了吗？）。有谁知道首选方法？

这是查看您的选择的一些替代方法。但是首先，TDB的规则，来自鲍勃叔叔，我特别强调：

1. 除非要通过失败的单元测试，否则不允许编写任何生产代码。
2. 不允许编写任何足以导致失败的单元测试。编译失败就是失败。
3. 您不能编写任何足以通过一项失败的单元测试的生产代码。

因此，读取规则编号3的一种方法是，您需要merge通过测试的功能，因此可以实现它-但只能以其最基本的形式实现。

或者，也可以从内联编写合并操作开始，然后在使测试生效后将其重构为函数。

另一种解释是，您正在编写mergesort，知道您需要一个merge操作（即，不是YAGNI，这是“足够”的规则试图减少的操作）。因此，您应该从合并测试开始，然后再进行整体排序测试。