• 4 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

Ce cours est en vidéo.

Vous pouvez obtenir un certificat de réussite à l'issue de ce cours.

J'ai tout compris !

Mis à jour le 07/10/2017

Découvrez le Test-Driven Development

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

 

Cette partie nous permettra d'ajouter une nouvelle fonctionnalité à notre programme. Youpi ! Nous allons enfin avoir une preuve scientifique que les grands-parents sont plus bougons que les enfants ! ;-)

Nous pourrions tout à fait ajouter la fonctionnalité, puis la tester en exécutant un script avec des arguments divers et enfin créer une pull-request sur Github. Ou bien la tester manuellement ! Mais nous allons faire un peu différemment ! Nous allons nous laisser guider par les tests pour créer la fonctionnalité.

Mais les tests font exactement ce que nous leur demandons de faire, non ?

Les tests vérifient que notre code renvoie ce que nous lui demandons. En soi, nous pourrions tout à fait comprendre notre programme uniquement en lisant les tests ! La suite de tests fait alors office de documentation puisque nous y lisons des exemples d'utilisation de notre programme.

Le Test-Driven Development

Présentation

Je ne sais pas vous, mais moi j'ai parfois tendance à écrire plus de code que nécessaire. Il est assez facile d'oublier la fonctionnalité que nous souhaitons ajouter car nous sommes perdu·e·s dans la recherche d'un bogue ou dans un enchevêtrement de fonctions.

Ecrire les tests en premier vous permet de vous souvenir de ce que vous êtes en train de construire. Vous pouvez le visualiser comme un fil rouge qui vous guide dans la jungle de votre programme !

Le Test-Driven Development (TDD), ou développement piloté par les tests, est une technique de développement qui préconise d'écrire les tests avant le code source d'un logiciel.

Kent Beck, le créateur de la méthodologie de projet agile Extreme Programming, a développé cette technique dans les années 2000. Elle s'est par la suite largement répandue dans le monde.

La technique repose sur trois phases complémentaires :

  • 🔴  Red : Ecrire un test unitaire puis le lancer. Evidemment, il échoue.

  • ✅  Green : Ecrire le code source qui permet de faire passer le test.

  • 🛠  Refactor : Améliorer le code source.

Avantages

Quels sont les avantages du TDD ? Pourquoi s'astreindre à suivre ces règles et ce processus ?

Uncle Bob, dans cette fantastique vidéo, nous rappelle les avantages principaux à suivre une démarche TDD :

  • Temps de débogage réduit : Vous passez moins de temps à déboguer car votre code est testé en détail,

  • Confiance : Vous gagnez en confiance et en flexibilité.

  • Documentation : Vos tests deviennent votre documentation et il est plus facile pour d'autres développeurs de l'utiliser,

  • Design : Votre code s'améliore car il devient plus modulaire et facile à tester.

Utilisons notre nouvelle fonctionnalité pour détailler chaque étape !

Nous savons que nous aurons à écrire plusieurs tests pour vérifier que plusieurs aspects de notre fonctionnalité ont bien le comportement que nous en attendons. Chaque test unitaire étant différent, nous appliquerons le cycle  red / green / refactor  pour chacun d'eux, un après l'autre.

Faisons une démonstration avec un aspect de notre nouvelle fonctionnalité : son titre.

Les étapes du TDD

 

Un cycle en TDD. Source : Wikipedia
Un cycle en TDD. Source : Wikipedia

 

🔴  Red

La première étape consiste à écrire un test puis à le lancer. Ici, nous allons écrire un test qui vérifie qu'un graphique de type "Agréabilité par âge" a bien un titre.

Si nous le lançons, nous voyons que le test est rouge. C'est normal : nous n'avons pas encore de classe qui permet de construire ce graphique !

✅  Green

Puis nous allons écrire le strict minimum qui nous permettra de faire passer notre test. Pendant cette étape, le code n'a pas vocation à être très lisible ou efficace. Vous pouvez, par exemple, dupliquer des lignes, utiliser des structures conditionnelles en enfilade ou écrire des noms de variable pas très représentatifs.

Voyez cette étape comme un bac à sable dans lequel vous pouvez expérimenter différentes solutions jusqu'à ce que votre test soit validé.

Vos tests doivent tous être verts à la fin de cette étape !

🛠  Refactor

Enfin, la dernière étape consiste à rendre votre code "présentable". Vous travaillez le nom des variables, évitez les duplicatas inutiles, ... Etant donné que vos tests sont verts, vous pouvez modifier votre code sans craindre de tout casser. Si les modifications en cassent une partie, les tests vous l'indiqueront tout de suite !

Cette étape est souvent l'occasion de travailler avec un·e autre développeur·se afin d'avoir un avis externe !

Quand votre code est "refactoré", vous commencez le test suivant !

 

La cerise sur le gâteau 

En bonus, regardez cette formidable vidéo de Robert C. Martin (dit Uncle Bob) qui reprend tous ces points en détail !

 

Exemple de certificat de réussite
Exemple de certificat de réussite