Introduction

Le développement piloté par les tests est une méthode efficace pour garantir un code bien testé et refactorisable. L'idée de base est que vous commencez le développement en écrivant des tests. Ces tests documentent clairement les attentes et créent une rubrique pour une mise en œuvre réussie. Lorsque cela est fait correctement, vous pouvez définir clairement l'entrée/sortie attendue d'une fonction avant d'écrire un code. Cela présente quelques avantages immédiats :

• Vous examinez attentivement l'interface pour interagir avec votre code et la concevez pour qu'elle soit testable
• Lorsque vous commencez à écrire du code, votre flux n'est pas interrompu par des tests manuels ou par une logique d'exécution pas à pas pour prédire le résultat. Au lieu de cela, vous exécutez simplement les tests
• Réussir un test devient un objectif satisfaisant à atteindre. Décomposer le processus en une série d'étapes bien définies et réalisables rend le travail plus agréable
• Évitez la paresse post-implémentation et l'excès de confiance qui pourraient vous empêcher de tester votre code

Maintenant que vous êtes convaincu des avantages, vous pouvez vous lancer dans le développement piloté par les tests (TDD) en suivant ces étapes :

1. Écrire ou modifier des tests
2. Vérifier si le test échoue
3. Écrivez la quantité minimale de code pour que les tests réussissent

Ces étapes sont suivies dans un cycle afin que vous ajoutiez toujours plus de tests pour contester la mise en œuvre actuelle.

La dernière étape, qui spécifie l'écriture de la quantité minimale de code, est celle où les choses peuvent devenir fastidieuses si elles sont suivies de manière rigide. Il est important de comprendre pourquoi cette règle existe avant de pouvoir déterminer quand il convient de s'en écarter.

Exemple simple

Vous êtes chargé d'implémenter la fonction Add(x, y int) int. Avant de passer à l'implémentation et de renvoyer simplement x y, écrivez le test le plus simple : 1 1 == 2. Ensuite, quelle est l'implémentation la plus simple qui réussirait le test ? C'est juste le retour 2. Maintenant, vos tests réussissent !

À ce stade, vous réalisez que vous avez besoin de plus de tests, alors vous accélérez le rythme et en ajoutez quelques autres :

• 1 2 == 3
• 100 5 == 105

Maintenant, vos tests échouent, vous devez donc corriger l'implémentation. Vous ne pouvez pas simplement renvoyer 3 ou renvoyer 105 cette fois, vous devez donc trouver une solution qui fonctionne pour tous les tests. Cela conduit à l'implémentation : return x y.

Bien que cela semble trop fastidieux dans l'exemple trivial, le strict respect de cette méthode vous a amené à écrire plusieurs tests au lieu de simplement faire confiance à votre implémentation. Bien sûr, votre idée initiale de renvoyer x y aurait fonctionné, mais le but est de vous recycler pour vous fier aux tests plutôt qu'à votre propre compréhension du code. Dans le monde réel, vous n'êtes pas le seul à travailler sur ce morceau de code et vous oublierez inévitablement les détails d'implémentation. Ce processus vous oblige à écrire plus de tests et à réfléchir à davantage de façons de rompre avec une implémentation simple.

Au final, vous acquerrez de l'expérience et apprendrez à trouver l'équilibre qui fonctionne dans les différents scénarios que vous rencontrez. Vous reviendrez à l'implémentation à pleine vitesse des fonctionnalités, constaterez que vous avez moins de bogues et écrirez du code plus maintenable.

TDD étape par étape pour une API HTTP

Passons à un exemple plus compliqué utilisant TDD pour une API HTTP REST. Ce guide étape par étape utilise mon framework Go, babyapi, mais les concepts peuvent être appliqués n'importe où.

babyapi utilise des génériques pour créer une API CRUD complète autour des structures Go, ce qui rend très facile la création d'une API REST complète et d'une CLI client. En plus de cela, le package babytest fournit des outils pour créer des tests de tables API de bout en bout. L'utilisation de TDD au niveau de l'API permet de tester entièrement les couches HTTP et de stockage d'une nouvelle API ou fonctionnalité en même temps.

Avertissement : étant donné que babyapi gère la majeure partie de l'implémentation et est également utilisé pour générer un passe-partout de test, nous ne commençons pas techniquement par TDD. Cependant, nous verrons à quel point cela est bénéfique lors de l'ajout du support des requêtes PATCH à notre API.

1. Créer un nouveau projet Go
   

2. Créez le main.go initial en utilisant l'exemple simple de babyapi
   

3. Utilisez la CLI pour générer un passe-partout de test
   

4. Implémentez chaque test en remplissant les espaces réservés avec le JSON attendu
   

5. Exécutez les tests et voyez s'ils réussissent !

6. Puisque PUT est idempotent, tous les champs doivent être inclus. Pour éviter cela, nous souhaitons ajouter la prise en charge du basculement des requêtes Terminé avec PATCH. Nous commençons par ajouter un test simple pour déterminer à quoi nous attendons cette fonctionnalité
   

7. Ce test échoue car babyapi ne prend pas en charge PATCH par défaut. Nous pouvons résoudre ce problème en implémentant Patch pour la structure TODO. Puisque nous avons défini notre fonctionnalité avec deux tests, notre implémentation la plus simple ne consiste pas simplement à définir Completed = true et nous devons utiliser la valeur de la requête
   

8. Nous pouvons désormais modifier le statut Terminé d'un TODO, mais nous ne pouvons toujours pas utiliser PATCH pour modifier d'autres champs, comme le montre ce nouvel ensemble de tests
   

9. Mettre à jour le correctif pour définir les champs restants
   

10. Nos tests échouent toujours puisque nous mettons toujours à jour le TODO avec les champs de requête, même s'ils sont vides. Corrigez ce problème en mettant à jour l'implémentation pour vérifier les valeurs vides
    

11. Le nouveau test UpdateWithPatch réussit, mais nos tests précédents échouent. Depuis que nous avons modifié Completed pour qu'il soit *bool, les TODO créés avec une valeur vide s'afficheront comme null
    

12. Implémentez le rendu pour TODO afin que nous puissions traiter zéro comme faux
    

La mise en œuvre de la fonctionnalité PATCH avec un développement piloté par les tests a abouti à un ensemble de tests robustes et à une fonctionnalité bien implémentée. Depuis que nous avons commencé par définir l'entrée et la sortie attendues d'une requête PATCH dans les tests, il était facile de voir les problèmes causés par la non-vérification des valeurs vides dans la requête. De plus, nos tests préexistants ont pu protéger contre les modifications brutales lors du changement du type de Terminé en *bool.

Conclusion

Le développement piloté par les tests est une approche efficace pour créer un code entièrement testé et correct. En commençant par les tests à l'esprit, nous pouvons garantir que chaque élément de code est conçu pour être testable au lieu de laisser les tests être une réflexion après coup.

Si vous hésitez à adopter le TDD, voici quelques idées pour commencer :

• Essayez-le dans des scénarios simples où les entrées/sorties d'une fonction sont claires et la mise en œuvre n'est pas trop compliquée. Vous pouvez écrire un test de table robuste pour la variété d'entrées/sorties qui pourraient être rencontrées. Avoir un visuel clair des différents scénarios peut simplifier la mise en œuvre
• Si vous corrigez un nouveau bug, vous avez déjà identifié une lacune dans vos tests. Commencez par écrire un test qui aurait identifié ce bug en premier lieu. Ensuite, faites réussir ce test sans interrompre les tests existants.
• Semblable à l'exemple babyapi, vous pouvez utiliser TDD pour les tests API de haut niveau. Une fois que vous avez défini la requête/réponse attendue, vous pouvez reprendre votre flux de développement habituel pour des parties plus détaillées de l'implémentation

Même si TDD ne convient pas à la façon dont vous écrivez du code, c'est toujours un outil puissant à avoir à votre actif. Je vous encourage à consacrer au moins un peu de temps à l'essayer et à voir comment cela affecte votre processus de développement.