Les approches des développement Agile apportent non seulement un état d’esprit, mais également un ensemble de pratiques qu’il est essentiel de suivre si l’on souhaite obtenir un produit de qualité. La pratique du TDD, ça vous parle ? C’est encore un de ces acronymes à la mode ? Je vous propose de rentrer dans le détail pour comprendre le principe et ce que cela peut vous apporter.

Tout d’abord, intéressons-nous aux raisons qui nous poussent à écrire des tests unitaires.

La première est de s’assurer que les règles métier sont bien implémentées. Il est en effet important que chacun des cas métier de notre application soient bien couverts par un test unitaire ; cela afin d’être certain d’en couvrir tous les besoins fonctionnels.

La seconde est de se donner la possibilité d’effectuer à tout moment un refactoring sans avoir peur d’insérer des régressions dans les fonctionnalités existantes.

La troisième est, si le test est bien écrit et commenté avec un nommage explicite, d’apporter une première documentation fonctionnelle. Cette dernière peut paraître anodine mais elle est très importante. On constate à l’usage que la durée de vie d’un code de test est plus grande que celle d’un code de production, d’où l’importance de sa qualité.

Usuellement et historiquement, les tests unitaires sont écrits après avoir développé la fonctionnalité.

Il s’agit en réalité d’une pratique à proscrire car elle peut être source de défauts. On développe souvent une fonctionnalité en essayant de penser à tous les cas possibles et, ce faisant, on arrive à prendre en compte des cas inutiles et à en oublier certains. Cela entraîne donc du code inutile (overdesign) qui cause une perte de temps et peut même parfois causer de nouveaux bugs. Il y a également un risque à tester le code écrit plutôt que la règle métier associée ; en effet, si le code est mal écrit et ne répond pas au besoin, alors le test correspondant va passer, mais sera fonctionnellement faux. Enfin, et il s’agit certainement de l’écueil le plus fréquent, la dé-priorisation des tests fait qu’ils sont négligés, voire sacrifiés, notamment quand on est sous l’eau.

You Aren’t Gonna Need It

Contrairement à une méthode de test traditionnelle, le TDD consiste à écrire une fonctionnalité en commençant par les tests. Un ensemble d’étapes permettent de s’assurer que nous suivons bien un cycle de développement TDD.

Ce cycle de développement, appelé cycle de la Mantra (ou RGR : Red Green Refactor), doit être le plus court et le plus simple possible. Il est primordial de ne valider qu’un comportement à la fois (on a tendance à conseiller « une méthode par cas de test »). Cette méthode entraîne également un refactoring fréquent (à chaque fois que l’on termine un cas de test) qui permet d’atteindre un niveau élevé de qualité de code. Attention, cette phase de refactoring permet d’améliorer, simplifier et optimiser le code, mais sans altérer son comportement ni ajouter de nouvelles fonctionnalités. Pour couvrir un maximum de cas d’usage, il est important de commencer par les cas nominaux pour aller jusqu’aux cas limites.

Quel que soit le paradigme utilisé pour écrire un test, il est essentiel qu’il soit structuré. Pour cela, il est conseillé d’utiliser la méthode dite des 3A : Arrange (initialisation des entrants), Act (exécution de la méthode à tester), Assert (vérification que le résultat est bien conforme à celui attendu). Cet outil permet non seulement de s’assurer de l’uniformité de l’ensemble des tests, mais également de rester concentré sur l’essentiel.

Le TDD est une pratique de test simple, mais dont la mise en œuvre peut s’avérer complexe. C’est pourquoi il est important d’éviter un certain nombre d’erreurs, parmi lesquelles :

• Rajouter des assertions dans un test existant (il ne faut pas oublier qu’un test = un cas métier ; une nouvelle assertion équivaut généralement à un nouveau cas métier, donc un nouveau test)
• Avoir un trop grand nombre d’entrants (peut entraîner une perte de compréhension du test) souvent causé par un trop grand nombre de dépendances
• Tester un cas qui n’est même pas sensé être testé
• Tester du code trivial (accesseurs)
• Tester directement une doublure/mock (objet permettant de simuler un comportement)

L’écriture des tests unitaires par le TDD peut rebuter la plupart d’entre vous. Sa mise en oeuvre peut apparaître comme fastidieuse et le changement d’état d’esprit nécessaire peut vous paraître insurmontable. Néanmoins, je peux vous assurer qu’une fois qu’on y a goûté, il est très difficile de faire marche arrière. Les avantages sont nombreux et finalement assez simples, à savoir :

• Les tests sont effectivement écrits et correspondent au besoin métier
• Le code est beaucoup plus pertinent (car répondant à une problématique métier) et de meilleur qualité
• L’augmentation de la fréquence des cycles de feedback (la fonctionnalité étant découpée en de multiples tests, nous obtenons du feedback à l’écriture de chaque test mais également sur chacune des étapes du cycle de la Mantra)
• Les tests nous apportent une première documentation fonctionnelle (à condition qu’ils soient bien nommés et commentés)

Attention tout de même, ce n’est pas parce qu’on pratique le TDD que vos tests seront parfaits et répondront à l’ensemble des scénarios métiers. Les difficultés les plus fréquemment rencontrés sont :

• Le temps d’adaptation à la méthode, qui est nouvelle pour la plupart des développeurs, et donc le coût de mise en oeuvre qu’elle peut engendrer
• La discipline qu’il faut se forcer à avoir, dans un premier temps du moins, pour suivre correctement les différentes étapes du cycle
• Et surtout, la pertinence des tests. Pour être certain que ce dernier point soit bien suivi, il est possible d’utiliser une autre méthode préconisée, et citée en préambule de cet article : le BDD. Mais ce sujet étant assez vaste, il fera l’objet d’un autre article.