Lorsque vous commencez à apprendre le développement piloté par les tests, cela semble simple et facile. Si comme moi vous l’avez appris en 1999, la règle était simplement d’écrire vos tests unitaires d’abord. En effet, à l’époque, nous appelions cela la conception préalable par les tests.

En 1999, je me suis assis à côté de Kent Beck et me suis mis à travailler en binôme avec lui pour apprendre. Ce qu’il m’enseigna fût certainement de faire d’abord les tests ; mais cela impliquait un processus plus fin que ce que j’avais pu voir jusqu’à présent. Il écrivait une ligne d’un test qui échouait, puis il écrivait la ligne de code de production correspondante pour faire passer le test. Quelques fois, c’était un peu plus qu’une ligne ; mais l’échelle de grandeur qu’il utilisait était très proche du ligne à ligne.

Seconde par seconde : le nano cycle : les trois lois du TDD

Quelques années plus tard, cette granularité fine fut codifiée en 3 règles : les fameuses trois lois du TDD.

  1. Vous devez écrire un test qui échoue avant d’écrire tout code de production
  2. Vous ne devez pas écrire plus d’un test suffisant pour échouer, ou qui échouera à la compilation
  3. Vous ne devez pas écrire plus de code que nécessaire pour faire passer le test en cours

Au fur et à mesure des années, moi, et beaucoup d’autres, avons écrit sur ces trois lois. Elles existent maintenant sous différents styles, formats et injonctions. Mais le but a toujours été de promouvoir la granularité ligne à ligne que j’avais expérimenté à l’époque avec Kent.

Ces trois lois sont le nano-cycle du TDD. Vous les suivez presque seconde par seconde. Vous allez itérer dessus une douzaine de fois ou presque avant de finir un seul test unitaire.

Minute par minute : le micro cycle : Rouge-Vert-Refactorer

Si nous revenons à une échelle de grandeur minute par minute, nous voyons le micro cycle que suivent les pratiquants du TDD. Le cycle Rouge-Vert-Refactorer.

Ce cycle est exécuté généralement une fois par test terminé, ou une fois toutes les douzaines de cycles des trois lois. Les règles de ce cycle sont simples.

  1. Créer un test unitaire qui échoue
  2. Écrire le code de production qui fera passer ce test
  3. Nettoyer le bordel que vous avez mis

Cette philosophie est basée sur l’idée que nos intellects limités ne sont pas capables de poursuivre deux objectifs simultanément de tout système informatique : 1. Corriger le comportement, 2. Corriger la structure. Le cycle RVR nous indique que le premier objectif est de faire un logiciel qui fonctionnement correctement ; et ensuite, et seulement à ce moment-là , de se concentrer de donner à ce logiciel opérationnel une structure qui tienne à long terme.

Là aussi, beaucoup de personnes ont écrit sur ce cycle. En effet, l’idée dérive de l’injonction originelle de Kent Beck :

Faites-le fonctionner, faites-le bien, faites-le vite

Une autre manière de considérer cette idée, c’est :

Faire fonctionner un logiciel, c’est seulement la moitié du boulot

Deux choses sont importantes aux yeux des clients à propos d’un logiciel. La manière dont il fait se comporter une machine ; et la facilité avec laquelle il peut être modifié. Un compromis sur l’une ou l’autre de ces deux valeurs et le logiciel aura moins de valeur pour les clients.

Exécuter le cycle rouge/vert/refactorer prend environ une minute. C’est la granularité du refactoring. Le refactoring n’est pas quelque chose que vous faites à la fin du projet : c’est quelque chose que vous faites minute par minute. Il n’existe aucune tâche sur le plan projet qui indique : refactoring. Il n’y a pas de temps réservé à la fin du projet, ou de l’itération, ou de la journée pour le refactoring. Le refactoring est un activité continue, pas quelque chose qui est effectuée tardivement (et donc optionnellement).

Déca-minute par déca-minute : le milli cycle : spécifique/générique

En remontant au niveau des 10 minutes, nous voyons le milli cycle en action. Le cycle spécifique/générique.

Au fur et à mesure que les tests deviennent plus spécifiques, le code devient plus générique.

Au fur et à mesure qu’une suite de tests grossie, elle devient plus spécifique, c’est à dire qu’elle devient une spécification du comportement encore plus détaillée. Les bons développeurs d’applications font face à cet accroissement de spécifications par un accroissement de la généricité de leur code. Pour le dire autrement : les développeurs font fonctionner des cas spécifiques en écrivant du code qui fait fonctionner le cas général.

En règle générale, le code de production devient de plus en plus générique si vous pouvez penser aux tests que vous n’avez pas écrit ; mais que le code de production pourra faire passer tout de même. Si le changement que vous faites dans le code pour faire suite à un test, fais passer ce test, mais qu’il ne pourrait pas faire passer d’autres tests non écrits, alors vous êtes sûrement en train de faire un code de production trop spécifique.

Il est souvent dit que la structure fine des trois lois et du cycle rouge/vert/refactorer conduisent à des optimisations locales. Sans un “ schéma général “, le développeur ne peut donner au logiciel une structure correcte pour répondre au problème global, et peut conduire à la place à la mise en place d’une structure correcte pour le cas spécifique, mais incorrecte pour le cas général.

Le symptôme de l’optimisation locale est “ d’être bloqué “. Afin de faire passer le prochain test, vous devez écrire une grosse quantité de code en dehors du nano cycle des trois lois, et même en dehors du micro cycle du RVR. Autrement dit, vous avez pris un chemin qui vous force à sortir du processus du TDD.

Une fois que vous êtes bloqué, la seule solution est de faire marche arrière sur les tests précédents, de les supprimer, jusqu’à que vous trouviez un test à partir duquel vous pourrez prendre un chemin différent.

Pourquoi avez-vous été bloqué ? Parce que vous n’avez pas inclus assez de généricité au code de production. Vous avez rendu les tests trop spécifiques trop rapidement. La solution est de faire marche arrière et d’ajouter des spécificités aux tests plus lentement, tout en ajoutant de la généricité au code de production plus rapidement. Cela vous force plus fréquemment à choisir un jeu de tests différent à suivre.

Pour éviter d’être bloqué, nous évaluons notre position toutes les quelques minutes ; en recherchant les spécificités dans le code de production. Avons-nous pris des raccourcis pour rendre le code de production plus semblable aux tests d’une quelconque manière ? Est-ce que les modifications récentes au code de production ne permettent plus de faire passer plus de tests que nous n’en avions écrits ?

C’est ce cycle que nous appliquons dans la prémisse prioritaire de la transformation. Nous recherchons les symptômes de la sur-spécification en vérifiant les types de code de production que nous avons écris.

Heure par heure : Le cycle primaire heure par heure : les limites

Le dernier cycle du TDD est le cycle primaire qui permet aux autres cycles de nous conduire vers une architecture propre. Toutes les heures ou presque, nous nous arrêtons et vérifions si nous avons franchis, ou atteint, une limite architecturale significative. Souvent ces limites sont difficiles à voir en plein nano ou micro cycle. Vous pouvez commencer à les percevoir au niveau déca-minute, même si notre attention est encore trop étroitement focalisée.

Ainsi chaque heure ou presque, nous nous arrêtons et regardons le système dans sa globalité. Nous recherchons les limites que nous voulons contrôler. Nous prenons les décisions où tracer ces limites, et de quel côté de ces limites, nos activités actuelles devraient être contraintes. Ensuite, nous utilisons nos décisions pour reprendre de manière avisée les nano cycles, les micro cycles, et les milli cycles pour l’heure suivante - le cycle primaire - du développement piloté par les tests.

Auteur : Uncle Bob
Source : The Cycles of TDD
Date de parution originale : 17 Décembre 2014

Traducteur : Nicolas Mereaux
Date de traduction : 06/01/2015

Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.