¿Se puede aplicar la metodología TDD de arriba a abajo?

No estoy claro cómo TDD, la metodología, maneja el siguiente caso. Supongamos que quiero implementar el algoritmo mergesort, en Python. Empiezo escribiendo

assert mergesort([]) === []

y la prueba falla con

NameError: el nombre 'mergesort' no está definido

Luego agrego

def mergesort(a):
    return []

y mi prueba pasa A continuación agrego

assert mergesort[5] == 5

y mi prueba falla con

AserciónError

que hago pasar con

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

A continuación, agrego

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

y ahora tengo que intentar hacer que esto pase. "Conozco" el algoritmo mergesort, así que escribo:

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

Y esto falla con

NameError: el nombre 'fusionar' no está definido

Ahora aquí está la pregunta. ¿Cómo puedo salir corriendo y comenzar a implementar mergeusando TDD? Parece que no puedo porque tengo esta prueba de "suspensión" sin cumplir mergesort, que no se cumplemerge , ¡ que no pasará hasta que termine! Si esta prueba se detiene, realmente nunca puedo hacer TDD porque no seré "verde" durante la construcción de las iteraciones de TDD merge.

Parece que estoy atrapado en los siguientes tres escenarios feos, y me gustaría saber (1) cuál de estos prefiere la comunidad TDD, o (2) ¿hay otro enfoque que me estoy perdiendo? ¡He visto varios recorridos del Tío Bob TDD y no recuerdo haber visto un caso como este antes!

Aquí están los 3 casos:

1. Implemente la fusión en un directorio diferente con un conjunto de pruebas diferente.
2. No se preocupe por ser ecológico cuando desarrolle la función auxiliar, solo realice un seguimiento manual de las pruebas que realmente desea aprobar.
3. Comente (GASP!) O elimine las líneas en mergesortesa llamada merge; luego, después de llegar mergeal trabajo, vuelva a colocarlos.

Todo esto me parece tonto (¿o estoy mirando esto mal?). ¿Alguien sabe el enfoque preferido?

Aquí hay algunas formas alternativas de ver sus opciones. Pero primero, las reglas de TDD, del tío Bob con énfasis en mí:

1. No está permitido escribir ningún código de producción a menos que sea para aprobar una prueba de unidad que falla.
2. No se le permite escribir más de una prueba unitaria de la que es suficiente para fallar; y las fallas de compilación son fallas.
3. No está permitido escribir más código de producción del que sea suficiente para pasar la prueba de una unidad que falla.

Entonces, una forma de leer la regla número 3 es que necesita la mergefunción para pasar la prueba, de modo que pueda implementarla, pero solo en su forma más básica.

O, alternativamente, comienza escribiendo la operación de fusión en línea, y luego la refactoriza en una función después de hacer que la prueba funcione.

Otra interpretación es que está escribiendo mergesort, sabe que necesitará una mergeoperación (es decir, no es YAGNI, que es lo que la regla "suficiente" intenta reducir). Por lo tanto, debería haber comenzado con las pruebas para la fusión, y solo luego continuar con las pruebas para la clasificación general.