Il ne semble pas naturel de commencer son développement informatique par les tests. Comment est-ce possible vu que l’on n’a rien à tester ? N’est-ce pas mettre la charrue avant les bœufs ?
On pourrait le penser à première vue, mais il en est autrement. L’approche TDD (issue de la méthode XP pour eXtreme Programming) consiste à dire que la façon dont nous allons écrire nos tests va piloter la manière dont nous allons développer notre fonctionnalité. C’est une forme originale qui a pour but premier d’aider aux spécifications. La fonctionnalité est vue comme le moyen de prouver que celle-ci répond à tous les cas de tests que l’on a imaginé en amont. C’est une approche itérative. Cette méthode est particulièrement efficace, car elle s’intègre parfaitement avec un CI-CD. De plus, pris dans ce sens, on a plus facilement la garantie que nos développements vont passer les tests puisqu’on implémente la fonctionnalité pour répondre à cet objectif précis.
Dans l’idéal, une personne va écrire les tests et une autre va les implémenter (notion de pilote et co-pilote) mais il n’est pas rare qu’une seule et même personne fasse les deux.
Le développeur commence à écrire un test (une coquille vide) qui va donc échouer lors de son premier ...
Abonnement
tous les livres et vidéos ENI en illimité sans engagement
du livre imprimé ou du livre numérique