{"id":21416,"date":"2021-08-27T10:58:12","date_gmt":"2021-08-27T08:58:12","guid":{"rendered":"https:\/\/www.software-developer-india.com\/quest-ce-que-le-developpement-pilote-par-les-tests-ou-tdd\/"},"modified":"2021-08-27T10:58:14","modified_gmt":"2021-08-27T08:58:14","slug":"quest-ce-que-le-developpement-pilote-par-les-tests-ou-tdd","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/fr\/quest-ce-que-le-developpement-pilote-par-les-tests-ou-tdd\/","title":{"rendered":"Qu’est-ce que le d\u00e9veloppement pilot\u00e9 par les tests? Ou TDD ?"},"content":{"rendered":"\n

Qu’est-ce que le d\u00e9veloppement pilot\u00e9 par les tests? Ou TDD ?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

Le d\u00e9veloppement pilot\u00e9 par les tests ou TDD, comme on l’appelle affectueusement dans les cercles des d\u00e9veloppeurs, est un aspect important du processus de d\u00e9veloppement logiciel. Gr\u00e2ce \u00e0 cette approche, il est plus facile de tester les performances d’un code sp\u00e9cifique. Des cas de test pour chaque fonctionnalit\u00e9 de l’application logicielle sont cr\u00e9\u00e9s, et lorsqu’une fonctionnalit\u00e9 particuli\u00e8re \u00e9choue dans un test, le code est retravaill\u00e9 et de nouveaux codes sont cr\u00e9\u00e9s. Le nouveau code devrait \u00e9galement r\u00e9ussir le test et \u00eatre exempt de bogues. Le d\u00e9veloppeur ne doit \u00e9crire un nouveau code que si le test automatis\u00e9 du code a \u00e9chou\u00e9, il y aura donc un sc\u00e9nario de test pour chaque fonctionnalit\u00e9, aussi petite soit-elle. Et TDD consiste \u00e0 concevoir et d\u00e9velopper des tests pour chaque fonctionnalit\u00e9 de l’application. <\/p>\n\n

Le nom Test Driven Development indique que c’est le processus consistant \u00e0 effectuer des tests de la bonne mani\u00e8re qui pilote le d\u00e9veloppement du logiciel. Par cons\u00e9quent, le processus lui-m\u00eame tire ses racines de la m\u00e9thodologie Agile et de la programmation Extreme. Ce processus garantit que les d\u00e9veloppeurs cr\u00e9ent et maintiennent un code r\u00e9silient et \u00e0 long terme. <\/p>\n\n

Ainsi, le processus pour TDD consisterait \u00e0 \u00e9crire d’abord le test unitaire, et si le test \u00e9choue, \u00e0 impl\u00e9menter les modifications de code. Cela permet \u00e9galement d’\u00e9viter la duplication de code. Le tout fonctionne sur l’\u00e9criture et la correction des tests \u00e9chou\u00e9s avant le d\u00e9veloppement r\u00e9el. Cependant, pour que le TDD fonctionne avec succ\u00e8s, il serait conseill\u00e9 d’\u00e9crire les cas de test dans des cas de test simples. Pour une logique m\u00e9tier complexe, il serait vraiment difficile d’\u00e9crire une combinaison de cas de test et d’obtenir un succ\u00e8s total. Il est possible que vous manquiez d’\u00e9crire certains tests, ce n’est donc pas du tout une t\u00e2che facile. <\/p>\n\n

Diff\u00e9rence entre le TDD et les tests traditionnels<\/strong><\/h3>\n\n

Les tests traditionnels prennent plus de temps que le TDD et sont bas\u00e9s sur la r\u00e9p\u00e9tition d’un cycle court de d\u00e9veloppement. Le test est d’abord \u00e9crit depuis le d\u00e9but, puis le code du programme est \u00e9crit, suivi du comportement souhait\u00e9 du syst\u00e8me. Lorsque le test \u00e9crit est r\u00e9ussi (v\u00e9rification de l’exactitude du travail du code non \u00e9crit), une refactorisation du code \u00e9crit est effectu\u00e9e. <\/p>\n\n

Au d\u00e9part, TDD prendra \u00e9galement du temps, mais avec le temps, le d\u00e9veloppeur s’y habituera car le processus de d\u00e9veloppement deviendra plus structur\u00e9. Par exemple, lorsque vous engagez un d\u00e9veloppeur, il d\u00e9cidera quoi \u00e9crire, puis comment l’\u00e9crire. <\/p>\n\n

Les tests traditionnels r\u00e9ussissent lorsqu’ils d\u00e9tectent correctement un ou plusieurs d\u00e9fauts. Tout comme le m\u00eame que TDD. Trouver des d\u00e9fauts est en fait un bon signe car vous savez alors que vous devez r\u00e9soudre ce qui ne va pas et passer \u00e0 autre chose. TDD vous donne \u00e9galement plus de confiance lorsque vous publiez le programme et garantit qu’il r\u00e9pond aux exigences pour lesquelles il est d\u00e9fini. <\/p>\n\n

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\u00e9rifier si les tests fonctionneront conform\u00e9ment au plan. <\/p>\n\n

TDD vous offre une couverture de test \u00e0 100%, o\u00f9 les tests sont effectu\u00e9s pour chaque ligne de code, ce qui n’est pas le cas avec les tests traditionnels.<\/p>\n\n

Lorsque la port\u00e9e du projet est vraiment large, vous devez \u00eatre tr\u00e8s minutieux lors de la r\u00e9alisation des tests. Et il est possible que les tests soient retard\u00e9s et d\u00e9passent les contraintes de budget et de temps. <\/p>\n\n

TDD peut \u00eatre difficile \u00e0 \u00e9crire, et cela peut ralentir le temps de d\u00e9veloppement, mais cela porterait certainement ses fruits \u00e0 long terme. <\/p>\n\n

Un autre inconv\u00e9nient de TDD est que le concept est difficile \u00e0 appliquer au code existant. <\/p>\n\n

Il est toujours bon que le test \u00e9choue avant de publier un projet, car vous saurez alors que vous avez ex\u00e9cut\u00e9 un test valide. Gr\u00e2ce \u00e0 TDD, vous saurez que votre syst\u00e8me r\u00e9pond aux exigences pour lesquelles il a \u00e9t\u00e9 con\u00e7u. 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\u00e9pond \u00e0 toutes les exigences con\u00e7ues pour lui.<\/p>\n\n

Les diff\u00e9rentes \u00e9tapes d’un d\u00e9veloppement pilot\u00e9 par les tests<\/strong><\/h3>\n\n

Il y a trois \u00e9tapes diff\u00e9rentes de TDD : Rouge, Vert et Refactor<\/p>\n\n

Suivez cet ordre d’\u00e9tapes pour garantir que vous disposez de tests pour le code que vous \u00e9crivez, vous devez donc \u00e9crire les codes uniquement pour les tests que vous effectuez. <\/p>\n\n

La sc\u00e8ne rouge<\/strong><\/h3>\n\n

L’id\u00e9e de l’\u00e9tape rouge est de faire \u00e9chouer le test, et la phase la plus difficile aussi car le d\u00e9veloppement doit \u00e9crire le test contre aucun code. Les nouveaux d\u00e9veloppeurs 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\u00e9rience deviendra lisse. Le premier test est \u00e9crit sans \u00e9crire de code, et pour d\u00e9clarer la classe et la m\u00e9thode, et le test aura une erreur de compilation. L’\u00e9tape suivante consisterait \u00e0 corriger l’erreur de compilation et \u00e0 ex\u00e9cuter le test pour l’\u00e9chouer. Cela provoque le drapeau rouge.<\/p>\n\n

La phase verte<\/strong><\/h3>\n\n

Apr\u00e8s l’\u00e9tape rouge, la prochaine \u00e9tape serait d’\u00e9crire le code. Ce code devra passer le premier test. Le simple fait d’\u00e9crire suffisamment de code pour s’assurer que seul le premier test r\u00e9ussit est un obstacle auquel de nombreux d\u00e9veloppeurs sont initialement confront\u00e9s. Parce que lors du prochain test, il devrait \u00e9chouer, suivi d’un nouveau code pour les passer. <\/p>\n\n

\"\"<\/a><\/figure><\/div>\n\n

La phase du r\u00e9fracteur<\/strong><\/h3>\n\n

Dans les deux premi\u00e8res \u00e9tapes, o\u00f9 le test doit d’abord \u00e9chouer, puis le r\u00e9ussir, l’objectif \u00e9tait ensuite de r\u00e9ussir les tests. Mais dans la phase du r\u00e9fracteur, d’autres facteurs devront \u00eatre pris en compte comme la qualit\u00e9 du code, la maintenabilit\u00e9 du code, la lisibilit\u00e9 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 \u00e0 vous soucier de l’aspect fonctionnalit\u00e9 manquant, car lorsque les changements de code se produisent, les cas de test se conforment \u00e9galement automatiquement \u00e0 la partie fonctionnalit\u00e9.<\/p>\n\n

TDD s’int\u00e8gre bien dans la m\u00e9thodologie Agile<\/strong><\/h3>\n\n

Il est tout \u00e0 fait \u00e9vident que les exigences du projet peuvent changer bien au cours de la phase de d\u00e9veloppement, donc avoir TDD en collaboration avec le d\u00e9veloppement Agile en assurera le succ\u00e8s et construira des projets align\u00e9s sur les exigences du client. Avec le d\u00e9veloppement pilot\u00e9 par les tests, vous obtenez un retour plus pr\u00e9coce sur le projet sur lequel vous pouvez facilement travailler. <\/p>\n\n

Cela aiderait \u00e9galement \u00e0 anticiper et \u00e0 r\u00e9duire les goulots d’\u00e9tranglement critiques et garantirait que le projet avance comme pr\u00e9vu. Les \u00e9quipes de d\u00e9veloppeurs peuvent gagner beaucoup de temps car les tests sont cr\u00e9\u00e9s beaucoup plus t\u00f4t dans le d\u00e9veloppement du projet, et elles n’ont pas \u00e0 se soucier des scripts de test \u00e9tendus. <\/p>\n\n

Conclusion<\/strong><\/h3>\n\n

Le Test Driven Development est une technique qui prend en effet du temps, mais elle est pr\u00e9cieuse dans le sens o\u00f9 elle vous aidera \u00e0 conduire votre projet dans la bonne direction en obtenant des retours corrects sur le projet et en d\u00e9tectant les bogues. Cependant, c’est une bien meilleure option que les tests traditionnels car cela n\u00e9cessite plus de temps et d’argent. <\/p>\n\n

Liens int\u00e9ressants\u00a0:<\/p>\n\n

D\u00e9veloppement pilot\u00e9 par les tests: ce que c’est et ce qu’il n’est pas.<\/a><\/p>\n\n

Plus d’informations sur le d\u00e9veloppement pilot\u00e9 par les tests<\/a><\/p>\n\n

Photos : Toile<\/p>\n\n

\"\"<\/figure><\/div>\n\n

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\u00e9t\u00e9s informatiques, aux agences et aux services informatiques.<\/p>\n