La méthodologie TDD peut-elle être appliquée de haut en bas?

Je ne sais pas comment TDD, la méthodologie, gère le cas suivant. Supposons que je veuille implémenter l'algorithme de fusion, en Python. Je commence par écrire

assert mergesort([]) === []

et le test échoue avec

NameError: le nom 'mergesort' n'est pas défini

J'ajoute ensuite

def mergesort(a):
    return []

et mon test réussit. Ensuite j'ajoute

assert mergesort[5] == 5

et mon test échoue avec

AssertionError

avec qui je fais passer

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

Ensuite, j'ajoute

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

et je dois maintenant essayer de faire ce passage. Je "connais" l'algorithme de fusion, donc j'écris:

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

Et cela échoue avec

NameError: le nom «fusion» n'est pas défini

Voici maintenant la question. Comment puis-je exécuter et commencer à implémenter en mergeutilisant TDD? Il semble que je ne peux pas parce que j'ai ce "suspendre" non rempli, échec du test mergesort, qui ne passera pas tant que ce mergen'est pas terminé! Si ce test traîne, je ne pourrai jamais vraiment faire de TDD car je ne serai pas "vert" lors de la construction de mes itérations TDD merge.

Il semble que je sois coincé avec les trois scénarios laids suivants et que j'aimerais savoir (1) lequel de ceux-ci la communauté TDD préfère, ou (2) y a-t-il une autre approche qui me manque? J'ai regardé plusieurs procédures pas à pas d'oncle Bob TDD et je ne me souviens pas avoir vu un cas comme celui-ci auparavant!

Voici les 3 cas:

1. Implémentez la fusion dans un répertoire différent avec une suite de tests différente.
2. Ne vous inquiétez pas d'être écologique lorsque vous développez la fonction d'assistance, il vous suffit de suivre manuellement les tests que vous souhaitez vraiment passer.
3. Mettez en commentaire (GASP!) Ou supprimez les lignes de mergesortcet appel merge; puis après avoir commencé mergeà travailler, remettez-les en place.

Tout cela me semble stupide (ou est-ce que je regarde mal?). Quelqu'un connaît-il l'approche préférée?

Voici quelques façons alternatives d'examiner vos options. Mais d'abord, les règles de TDD, de l' oncle Bob avec emphase par moi:

1. Vous n'êtes pas autorisé à écrire un code de production, sauf pour effectuer un test unitaire échoué.
2. Vous n'êtes pas autorisé à écrire plus d'un test unitaire que ce qui est suffisant pour échouer; et les échecs de compilation sont des échecs.
3. Vous n'êtes pas autorisé à écrire plus de code de production qu'il n'en faut pour réussir le test unitaire ayant échoué.

Ainsi, une façon de lire la règle numéro 3 est que vous ayez besoin de la mergefonction pour réussir le test, afin que vous puissiez l'implémenter - mais uniquement sous sa forme la plus élémentaire.

Ou, vous pouvez également commencer par écrire l'opération de fusion en ligne, puis la refactoriser dans une fonction après avoir fait fonctionner le test.

Une autre interprétation est que vous écrivez mergesort, vous savez que vous aurez besoin d'une mergeopération (c'est-à-dire que ce n'est pas YAGNI, ce que la règle "suffisante" tente de limiter). Par conséquent, vous devriez avoir commencé avec des tests pour la fusion, puis seulement procéder à des tests pour le tri global.