Qu’est-ce que le développement piloté par les tests? Ou TDD ?

Qu’est-ce que le développement piloté par les tests? Ou TDD ?

Le développement piloté par les tests ou TDD, comme on l’appelle affectueusement dans les cercles des développeurs, est un aspect important du processus de développement logiciel. Grâce à cette approche, il est plus facile de tester les performances d’un code spécifique. Des cas de test pour chaque fonctionnalité de l’application logicielle sont créés, et lorsqu’une fonctionnalité particulière échoue dans un test, le code est retravaillé et de nouveaux codes sont créés. Le nouveau code devrait également réussir le test et être exempt de bogues. Le développeur ne doit écrire un nouveau code que si le test automatisé du code a échoué, il y aura donc un scénario de test pour chaque fonctionnalité, aussi petite soit-elle. Et TDD consiste à concevoir et développer des tests pour chaque fonctionnalité de l’application.

Le nom Test Driven Development indique que c’est le processus consistant à effectuer des tests de la bonne manière qui pilote le développement du logiciel. Par conséquent, le processus lui-même tire ses racines de la méthodologie Agile et de la programmation Extreme. Ce processus garantit que les développeurs créent et maintiennent un code résilient et à long terme.

Ainsi, le processus pour TDD consisterait à écrire d’abord le test unitaire, et si le test échoue, à implémenter les modifications de code. Cela permet également d’éviter la duplication de code. Le tout fonctionne sur l’écriture et la correction des tests échoués avant le développement réel. Cependant, pour que le TDD fonctionne avec succès, il serait conseillé d’écrire les cas de test dans des cas de test simples. Pour une logique métier complexe, il serait vraiment difficile d’écrire une combinaison de cas de test et d’obtenir un succès total. Il est possible que vous manquiez d’écrire certains tests, ce n’est donc pas du tout une tâche facile.

Différence entre le TDD et les tests traditionnels

Les tests traditionnels prennent plus de temps que le TDD et sont basés sur la répétition d’un cycle court de développement. Le test est d’abord écrit depuis le début, puis le code du programme est écrit, suivi du comportement souhaité du système. Lorsque le test écrit est réussi (vérification de l’exactitude du travail du code non écrit), une refactorisation du code écrit est effectuée.

Au départ, TDD prendra également du temps, mais avec le temps, le développeur s’y habituera car le processus de développement deviendra plus structuré. Par exemple, lorsque vous engagez un développeur, il décidera quoi écrire, puis comment l’écrire.

Les tests traditionnels réussissent lorsqu’ils détectent correctement un ou plusieurs défauts. Tout comme le même que TDD. Trouver des défauts est en fait un bon signe car vous savez alors que vous devez résoudre ce qui ne va pas et passer à autre chose. TDD vous donne également plus de confiance lorsque vous publiez le programme et garantit qu’il répond aux exigences pour lesquelles il est défini.

Dans les tests traditionnels, l’accent est davantage mis sur la conception des cas de test, tandis que dans TDD, l’accent est davantage mis sur le code de production pour vérifier si les tests fonctionneront conformément au plan.

TDD vous offre une couverture de test à 100%, où les tests sont effectués pour chaque ligne de code, ce qui n’est pas le cas avec les tests traditionnels.

Lorsque la portée du projet est vraiment large, vous devez être très minutieux lors de la réalisation des tests. Et il est possible que les tests soient retardés et dépassent les contraintes de budget et de temps.

TDD peut être difficile à écrire, et cela peut ralentir le temps de développement, mais cela porterait certainement ses fruits à long terme.

Un autre inconvénient de TDD est que le concept est difficile à appliquer au code existant.

Il est toujours bon que le test échoue avant de publier un projet, car vous saurez alors que vous avez exécuté un test valide. Grâce à TDD, vous saurez que votre système répond aux exigences pour lesquelles il a été conçu. L’accent est donc davantage mis sur le code de production pour TDD, car il garantit que les tests fonctionneront correctement. Et lorsque le logiciel répond à toutes les exigences conçues pour lui.

Les différentes étapes d’un développement piloté par les tests

Il y a trois étapes différentes de TDD : Rouge, Vert et Refactor

Suivez cet ordre d’étapes pour garantir que vous disposez de tests pour le code que vous écrivez, vous devez donc écrire les codes uniquement pour les tests que vous effectuez.

La scène rouge

L’idée de l’étape rouge est de faire échouer le test, et la phase la plus difficile aussi car le développement doit écrire le test contre aucun code. Les nouveaux développeurs doivent trouver cela difficile car ils ne savent pas quoi tester sans avoir le code pour cela. Mais c’est une chose habituelle et avec l’expérience deviendra lisse. Le premier test est écrit sans écrire de code, et pour déclarer la classe et la méthode, et le test aura une erreur de compilation. L’étape suivante consisterait à corriger l’erreur de compilation et à exécuter le test pour l’échouer. Cela provoque le drapeau rouge.

La phase verte

Après l’étape rouge, la prochaine étape serait d’écrire le code. Ce code devra passer le premier test. Le simple fait d’écrire suffisamment de code pour s’assurer que seul le premier test réussit est un obstacle auquel de nombreux développeurs sont initialement confrontés. Parce que lors du prochain test, il devrait échouer, suivi d’un nouveau code pour les passer.

La phase du réfracteur

Dans les deux premières étapes, où le test doit d’abord échouer, puis le réussir, l’objectif était ensuite de réussir les tests. Mais dans la phase du réfracteur, d’autres facteurs devront être pris en compte comme la qualité du code, la maintenabilité du code, la lisibilité du code, etc. L’accent est donc mis ici sur ces aspects, de sorte que les tests unitaires se concentreront sur ceux-ci. Dans la phase de refactorisation, vous n’avez pas à vous soucier de l’aspect fonctionnalité manquant, car lorsque les changements de code se produisent, les cas de test se conforment également automatiquement à la partie fonctionnalité.

TDD s’intègre bien dans la méthodologie Agile

Il est tout à fait évident que les exigences du projet peuvent changer bien au cours de la phase de développement, donc avoir TDD en collaboration avec le développement Agile en assurera le succès et construira des projets alignés sur les exigences du client. Avec le développement piloté par les tests, vous obtenez un retour plus précoce sur le projet sur lequel vous pouvez facilement travailler.

Cela aiderait également à anticiper et à réduire les goulots d’étranglement critiques et garantirait que le projet avance comme prévu. Les équipes de développeurs peuvent gagner beaucoup de temps car les tests sont créés beaucoup plus tôt dans le développement du projet, et elles n’ont pas à se soucier des scripts de test étendus.

Conclusion

Le Test Driven Development est une technique qui prend en effet du temps, mais elle est précieuse dans le sens où elle vous aidera à conduire votre projet dans la bonne direction en obtenant des retours corrects sur le projet et en détectant les bogues. Cependant, c’est une bien meilleure option que les tests traditionnels car cela nécessite plus de temps et d’argent.

Liens intéressants :

Développement piloté par les tests: ce que c’est et ce qu’il n’est pas.

Plus d’informations sur le développement piloté par les tests

Photos : Toile

L’auteur : Sascha Thattil travaille chez Software-Developer-India.com qui fait partie du groupe YUHIRO. YUHIRO est une entreprise germano-indienne qui fournit des programmeurs aux sociétés informatiques, aux agences et aux services informatiques.