Czy metodologię TDD można stosować odgórnie?

Nie jestem pewien, w jaki sposób TDD, metodologia, obsługuje następujący przypadek. Załóżmy, że chcę zaimplementować algorytm scalania w Pythonie. Zaczynam od pisania

assert mergesort([]) === []

a test kończy się niepowodzeniem

Nazwa Błąd: nazwa „scalanie” nie jest zdefiniowana

Następnie dodaję

def mergesort(a):
    return []

i mój test mija. Następnie dodaję

assert mergesort[5] == 5

i mój test kończy się niepowodzeniem

AssertionError

które przekazuję

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

Następnie dodaję

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

i teraz muszę spróbować to przekazać. „Znam” algorytm scalania, więc piszę:

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

I to się nie udaje

NameError: nazwa „merge” nie jest zdefiniowana

Oto pytanie. Jak mogę uciec i zacząć wdrażać mergeza pomocą TDD? Wygląda na to, że nie mogę, bo mam ten „wiszący” niespełniony, nieudany test mergesort, który nie przejdzie, dopóki się mergenie skończy! Jeśli ten test się zawiesi, nigdy tak naprawdę nie będę mógł wykonywać TDD, ponieważ nie będę „zielony” podczas konstruowania iteracji TDD merge.

Wygląda na to, że utknąłem w poniższych trzech brzydkich scenariuszach i chciałbym wiedzieć (1), który z nich preferuje społeczność TDD, lub (2) czy istnieje inne podejście, którego mi brakuje? Obejrzałem kilka instrukcji wujka Boba TDD i nie przypominam sobie, aby widziałem wcześniej taki przypadek!

Oto 3 przypadki:

1. Zaimplementuj scalanie w innym katalogu z innym pakietem testowym.
2. Nie martw się, że jesteś zielony podczas opracowywania funkcji pomocnika, po prostu ręcznie śledź, które testy naprawdę chcesz zdać.
3. Skomentuj (GASP!) Lub usuń linie w mergesorttym połączeniu merge; następnie po mergepowrocie do pracy włóż je z powrotem.

Wszystko to wygląda dla mnie głupio (a może patrzę na to źle?). Czy ktoś zna preferowane podejście?

Oto kilka alternatywnych sposobów sprawdzenia dostępnych opcji. Ale najpierw zasady TDD od wuja Boba z naciskiem przeze mnie:

1. Nie wolno pisać żadnego kodu produkcyjnego, chyba że ma to negatywny wynik pozytywnego testu jednostkowego.
2. Nie wolno pisać więcej testów jednostkowych niż jest to wystarczające do zaliczenia; awarie kompilacji to awarie.
3. Nie wolno pisać więcej kodu produkcyjnego, niż jest to wystarczające do zaliczenia jednego z nieudanych testów jednostkowych.

Tak więc jednym ze sposobów na odczytanie reguły nr 3 jest to, że potrzebujesz mergefunkcji, aby przejść test, abyś mógł ją wdrożyć - ale tylko w najbardziej podstawowej formie.

Lub, alternatywnie, zaczynasz od napisania operacji scalania w linii, a następnie przekształcasz ją w funkcję po uruchomieniu testu.

Inną interpretacją jest to, że piszesz w trybie scalania, wiesz, że będziesz potrzebować mergeoperacji (tzn. Nie jest to YAGNI, co właśnie „wystarczająca” reguła próbuje ograniczyć). Dlatego powinieneś zacząć od testów dla scalenia, a dopiero potem przejść do testów dla ogólnego sortowania.