Récemment, j’ai découvert un livre passionnant intitulé Software Craft. Fruit de la collaboration entre Cyrille Martraire, Arnaud Thiéfaine, Dorra Bartaguiz, Fabien Hiegel et Houssam Fakih, cet ouvrage plonge au cœur de l’artisanat logiciel. Il explore avec finesse les principes, les pratiques et l’état d’esprit nécessaires pour créer des logiciels de qualité, en mettant l’accent sur des valeurs clés comme la collaboration et l’amélioration continue.
Suite à cette lecture inspirante, j’ai pris des notes synthétiques dans mon espace Notion, que je vous partage ici :
Les trois règles du TDD :
- On doit écrire un test qui échoue avant d’écrire n’importe quel code de production.
- On ne doit pas écrire plus de tests que ce qui est nécéssaire pour échouer ou ne pas compiler.
- On ne doit écrire que le code suffisant pour que le test actuellement en échec réussisse.
Les 3 étapes (Itération) du TDD :
- Red (Le test ne passe pas)
- Green (Le test passe)
- Refactor (Amélioration du code pour une meilleure lisibilité)
L’étape 3 est requise seulement si il y a besoin d’une refactor
La rigueur de chaque étape est nécessaire pour performer dans le TDD.
Remarque : utiliser la règle de triangulation afin d’éviter les valeurs de retour en dur dans le code. Cela consiste à toujours écrire au moins deux tests avec des valeurs différentes. Cependant on ne doit pas le faire dès la première itération. le premier test doit être validé puis un nouveau test est écrit puis échoue ou ne compile pas.
Les règles d’écritures d’un test
Anatomie d’un test :
Concerne le nommage des fonctions de test et/ou des classes.
- should/when (ex : Should_raise_an_error_when_denominator_is_zero)
- given/when/then (ex: Given_five_as_nominator_and_zero_as_denominator_when_I_divide_nominator_by_denominator_then_an_error_is_raised)
Corp d’un test :
Règle du triple A : Arrange/Act/Assert.
La règle du triple A est une méthodologie de base pour écrire des tests unitaires pour un scénario unique. Elle est divisée en trois sections distinctes. La première section, « Arrange », implique la configuration du test. C’est ici que vous initialiserez les objets, définirez les valeurs ou entrerez les données nécessaires au test. La partie « Act » fait référence à l’exécution de l’action qui doit être testée, tandis que « Assert » est la phase où vous vérifierez si le résultat de l’action est le résultat attendu.
Écrire du code qui ne compile pas n’est pas intuitif mais avec la méthode TDD on apprend à lâcher prise et utiliser la puissance de l’IDE pour générer le code attendu.
Voici le code source d’un exemple ou chaque commit représente une étape du TDD : https://github.com/adrunor/FizzBuzz
Laisser un commentaire