Qu'est-ce que le développement piloté par les tests ?

Utilise la méthodologie TDD et la suite de tests fournie pour résoudre les exercices

Le développement piloté par les tests (parfois appelé développement à tests d'abord, ou conception pilotée par les tests) est la pratique qui consiste à écrire les tests unitaires en premier, avant d'écrire la moindre ligne de code d'implémentation.

Sur Exercism, les tests sont les exigences !

Tous les exercices d'entraînement sur lesquels tu travailles (ceux qui ne t'enseignent pas un nouveau concept) comportent des instructions qui décrivent en termes généraux ce que tu dois faire. Par construction, ces instructions ne tiennent pas compte des détails d'implémentation propres à chaque langage de programmation, car elles sont partagées par les plus de 70 parcours linguistiques d'Exercism. Certains parcours y ajoutent des détails plus précis, mais ce n'est pas le cas de tous.

Quand tu commences un exercice d'entraînement, prends le temps de lire les instructions attentivement. Elles te donnent une vue d'ensemble de la manière dont tu peux implémenter une solution. Mais tu devras lire les tests pour comprendre l'ensemble des exigences exactes :

  • Le résultat doit-il être un type particulier de structure de données ?
  • Le résultat doit-il être trié dans un certain ordre ?
  • Comment es-tu censé gérer les exceptions ? Et ainsi de suite.

Tu as résolu un exercice lorsque tous les tests fournis s'exécutent et passent. Autrement dit, ta solution n'est pas simplement une interprétation des instructions qui « semble correcte » : ta solution est un programme qui satisfait les tests fournis. Les tests représentent l'ensemble des exigences de l'exercice.

Comment Exercism applique-t-il le TDD ?

On a déjà fait le travail d'écrire une suite de tests unitaires pour toi. Ton objectif est d'écrire une solution qui contient juste assez de code pour faire passer tous ces tests unitaires.

Garde ceci en tête : l'approche TDD t'aidera à arriver à la solution, mais tu n'es pas obligé de t'arrêter là. Si tu veux aller au-delà des exigences, tu es libre de le faire. Si tu choisis de travailler avec un mentor (et on t'encourage à le faire dès que les tests passent), il peut t'aider à réécrire et à affiner ta première implémentation, voire te proposer de nouveaux tests unitaires.

Travailler dans l'éditeur en ligne

Quand tu travailles dans l'éditeur de code du site d'Exercism, tu peux lire les tests, mais tu ne peux pas les modifier. Tous les tests seront exécutés à chaque fois que tu les lances, quels que soient les mécanismes de skip indiqués dans le fichier de test.

Quand plusieurs tests échouent, le site n'affiche d'abord que le résultat du premier échec. Tu peux aussi cliquer sur les autres échecs pour les déplier ! Parfois, le premier résultat n'est pas le plus informatif.

Ne te décourage pas si beaucoup de tests échouent. Concentre-toi pour les faire passer un par un.

Travailler en local

Beaucoup de parcours utilisent des tests désactivés dans leurs fichiers de test. Au départ, seul le premier test est actif et les autres sont inactifs (la façon dont cela se fait varie selon le parcours). Quand tu lances la suite de tests dans ton environnement, seul le premier test s'exécute. On fait cela pour t'encourager à suivre ce workflow :

  1. Avant d'ajouter du nouveau code, lance la suite de tests : tu devrais voir un test qui échoue.
  2. Ajoute juste assez de code pour faire passer le test.
  3. Lance la suite de tests.
  4. Si le test échoue encore, répète l'étape 2.
  5. Une fois que le test passe, réécris ton code comme tu le souhaites, en veillant à ce que tous les tests actifs passent encore. La réécriture peut consister à :
    • supprimer le code dupliqué,
    • découper les fonctions longues en fonctions plus petites,
    • ajouter des commentaires, etc.
  6. Réactive le test suivant et reprends à l'étape 1.

Répète ces étapes jusqu'à ce que tu aies réactivé tous les tests. Une fois que tous les tests passent, félicitations, tu as résolu l'exercice !

La façon exacte de réactiver les tests dépend du parcours. Pour certains parcours, il peut s'agir de commenter ou de supprimer une annotation. Pour d'autres, de faire passer un attribut de true à false. Prends le temps de lire la documentation de ton parcours ; elle explique ces détails.

Pour les parcours qui ne désactivent pas les tests, appliquer ce workflow peut se résumer à commenter les tests et à les décommenter un par un.

L'intérêt du développement piloté par les tests

Même si cela peut sembler « mettre la charrue avant les bœufs », il y a plusieurs bonnes raisons d'écrire les tests unitaires avant le code d'implémentation.

  1. La conception. Cela t'oblige à réfléchir d'abord à l'interface de ton programme (la façon dont il expose ses fonctionnalités au monde), au lieu de te jeter directement sur la manière dont tu vas implémenter le code. Avoir une interface bien conçue (et testable !) est souvent plus important qu'avoir une implémentation efficace.

  2. La discipline. Écrire des tests est souvent perçu comme une corvée ou une réflexion après coup ; écrire les tests en premier garantit qu'au bout du compte, tu auras écrit assez de tests unitaires pour couvrir la majeure partie, voire la totalité, des fonctionnalités de ton code (au lieu de repousser sans cesse cette tâche).

  3. Moins de travail. Si tu appliques un cycle serré consistant à écrire un test, puis le code qui l'implémente, puis le test suivant, ton code finit par grandir de façon organique. Cela conduit souvent (mais pas toujours) à moins d'efforts gaspillés : tu finis par écrire tout le code dont tu as besoin, et aucun de celui dont tu n'as pas besoin.

Pour aller plus loin