Может ли методология TDD применяться сверху вниз?

Мне неясно, как TDD, методология, обрабатывает следующий случай. Предположим, я хочу реализовать алгоритм слияния в Python. Я начинаю с написания

assert mergesort([]) === []

и тест не проходит с

NameError: имя 'mergesort' не определено

Я тогда добавляю

def mergesort(a):
    return []

и мой тест проходит. Далее я добавляю

assert mergesort[5] == 5

и мой тест не проходит с

AssertionError

с которым я делаю пас

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

Далее я добавляю

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

и теперь я должен попытаться сделать это. Я «знаю» алгоритм слияния, поэтому пишу:

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' не определено

Теперь вот вопрос. Как я могу убежать и начать mergeиспользовать TDD? Кажется, что я не могу, потому что у меня есть этот «зависший» невыполненный, не пройденный тест mergesort, который не пройдет, пока mergeне закончится!Если этот тест зависает, я никогда не смогу сделать TDD, потому что я не буду «зеленым» во время построения итераций TDD merge.

Кажется, что я застрял в следующих трех уродливых сценариях и хотел бы знать (1) какой из них предпочитает сообщество TDD, или (2) есть другой подход, который мне не хватает? Я смотрел несколько прохождений дяди Боба TDD и не помню, чтобы видел такой случай раньше!

Вот 3 случая:

1. Реализуйте слияние в другом каталоге с другим набором тестов.
2. Не беспокойтесь о том, чтобы быть зеленым при разработке вспомогательной функции, просто следите за тем, какие тесты вам действительно нужны. хотите пройти.
3. Закомментируйте (GASP!) Или удалите строки в mergesortэтом вызове merge; затем, после mergeработы, положите их обратно.

Все это выглядит глупо для меня (или я смотрю на это неправильно?). Кто-нибудь знает предпочтительный подход?

Вот несколько альтернативных способов взглянуть на ваши варианты. Но сначала правила TDD, от дяди Боба с акцентом на меня:

1. Вам не разрешается писать какой-либо производственный код, если только он не прошел неудачный модульный тест.
2. Вам не разрешено писать больше модульных тестов, чем достаточно для провала; и ошибки компиляции - это ошибки.
3. Вам не разрешено писать больше производственного кода, чем достаточно для прохождения одного неудачного модульного теста.

Таким образом, один из способов прочитать правило № 3 заключается в том, что вам нужна mergeфункция для прохождения теста, чтобы вы могли ее реализовать - но только в ее самой базовой форме.

Или, альтернативно, вы начинаете с записи встроенной операции слияния, а затем переводите ее в функцию после запуска теста.

Другое объяснение состоит в том, что вы пишете сортировку слиянием, вы знаете, что вам понадобится mergeоперация (т. Е. Это не YAGNI, которую пытается «сократить» правило «достаточного»). Следовательно, вы должны были начать с тестов на слияние, и только затем приступить к тестам для общей сортировки.