Modifier

TL;DR

J'ajoute une étape de clarification entre l'étape Green et Refactoring. Cela permet de tricher et de gagner en vélocité dans le développement. On comprend mieux le code. Le schéma ci-dessous explique tout le processus TDD en détail.

Processus TDD : Red - Green - Refactoring

Si vous pratiquez TDD, vous devez connaître le processus TDD : red - green - refactoring.

L'étape red correspond à la mise en place d'un test qui échoue. Cette étape sert à mettre en évidence qu'une fonctionnalité ne marche pas. L'étape green vient juste après et correspond à la mise en place du code qui fait réussir le test. Cette étape sert à mettre en place la fonctionnalité.

On pourrait s'arrêter là et développer notre projet en suivant des étapes de red et de green.

Mais au bout d'un moment, si vous faîtes comme ça, vous allez commencer à pédaler dans la semoule. En effet, si vous ne prenez pas soin du code, vous allez commencer à avoir un gros tas de boue dans lequel il va être compliqué d'avancer.

C'est pourquoi, on a une étape de refactoring. C'est dans cette étape que vous devez améliorer le code pour continuer à être rapide dans votre développement.

Que l'on me donne six heures pour couper un arbre, j'en passerai quatre à préparer ma hâche. Citation (apocryphe ?) d'Abrahm Lincoln

Dans la citation ci-dessus, préparer sa hâche correspond au refactoring et couper l'arbre correspond aux étapes red et green.

Et la quatrième étape ?

J'ai mis en place cette quatrième étape pour pouvoir optimiser le temps que l'on passe dans l'étape Green. Pour passer l'étape green, il faut écrire le bout de code minimal faisant passer le test. Or, cette étape prend souvent trop de temps pour les développeurs qui débutent en TDD. Ils réfléchissent au code qu'ils doivent écrire avant de l'écrire. Or, cette étape green doit être passée le plus rapidement possible.

Comment faire ?

Il faut tricher ! Et oui, j'ai bien dit Tricher.

La triche est un des concepts les plus importants (à mon avis) de TDD. Renvoyer une valeur encodée, faire un copier coller où je ne sais quoi qui peut faire passer le test du rouge au vert en moins de 30 secondes peut faire penser à de la triche. Mais en faisant cela, on vient d'ajouter une nouvelle fonctionnalité à notre code.

OK, alors, je rajoute un if avec la valeur encodée et je fais du TDD ?

Tout à fait, cela fait partie de la pratique TDD. Mais elle n'est pas terminée sinon, on se retrouverait avec une infinitité de if et de valeur encodée dans notre code. Il faut rajouter une étape, la clarification.

La clarification

Cette étape ressemble énormément au refactoring, mais il y a une nuance.

Le refactoring consiste à changer la structure du code sans modifier le comportement. Malheureusement, lorsqu'on triche, le comportement attendu n'est pas tout à fait en place. Il peut manquer de la généricité. Il faut donc une étape où l'on va supprimer la triche et ajouter la généricité qui manque. L'application des TPP (transformation priority premises), si elle n'a pas été faite à l'étape green peut se faire à cette étape.

J'appelle cette étape la clarification (si vous avez un meilleur nom, je suis preneur).

C'est aussi à cette étape où l'on doit chercher à comprendre ce que doit faire le code. J'ai rencontré beaucoup de développeurs qui ne prenaient pas le temps de comprendre le code.

Elle se situe entre l'étape green et l'étape refactoring.

Le schéma

Pour comprendre tout le processus TDD, tel que je le pratique actuellement, vous pouvez étudier le schéma suivant :

Conclusion

En ajoutant cette étape, on se force à tricher beaucoup plus. L'utilisation de la triche rend le processus de développement plus fluide et on gagne beaucoup de temps. On arrête de réfléchir à l'étape green, c'est ce qui ralentit le plus. Forcez vous à tricher, forcez vous à clarifier.

Merci pour votre lecture.

Article suivant Article précédent

Blog Comments powered by Disqus.