{"id":10138,"date":"2022-01-26T01:34:13","date_gmt":"2022-01-26T01:34:13","guid":{"rendered":"https:\/\/www.cybermedian.com\/fr\/?p=10138"},"modified":"2026-04-20T09:13:19","modified_gmt":"2026-04-20T09:13:19","slug":"approche-de-developpement-test-drive-pour-le-developpement-logiciel-agile","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/fr\/test-drive-development-approach-for-agile-software-development\/","title":{"rendered":"Approche de d\u00e9veloppement test-drive pour le d\u00e9veloppement logiciel agile"},"content":{"rendered":"
\n
\n
\n

Maintenant, les gens parlent souvent de d\u00e9veloppement agile.<\/p>\n

Qu’est-ce que le d\u00e9veloppement agile ?<\/span><\/h4>\n

Le d\u00e9veloppement agile<\/a>\u00a0\u00a0est une capacit\u00e9 de d\u00e9veloppement logiciel qui r\u00e9pond \u00e0 des besoins en \u00e9volution rapide.\u00a0Leurs noms, concepts, processus et terminologie sp\u00e9cifiques varient.\u00a0Par rapport aux \u00ab\u00a0non agiles<\/a>\u00a0\u00bb, ils mettent l’accent sur une collaboration \u00e9troite entre les \u00e9quipes de programmeurs et les experts m\u00e9tier, la communication en face \u00e0 face (consid\u00e9r\u00e9e comme plus efficace que la documentation \u00e9crite), et livrent fr\u00e9quemment de nouvelles versions de logiciels, des \u00e9quipes petites et\u00a0\u00a0auto-organis\u00e9es<\/a>\u00a0\u00a0pour les petites \u00e9quipes.\u00a0et des approches d’\u00e9criture de fonctionnalit\u00e9s utiles et d’organisation d’\u00e9quipe qui s’adaptent \u00e0 l’\u00e9volution des besoins, en mettant davantage l’accent sur le r\u00f4le des personnes dans le d\u00e9veloppement de logiciels.<\/p>\n

Cependant, il existe plusieurs versions similaires des m\u00e9thodes de d\u00e9veloppement agiles TDD, telles que TDD : BDD, DDD et ATDD.\u00a0Permettez-moi de pr\u00e9senter bri\u00e8vement ces m\u00e9thodes avant de pr\u00e9senter TDD en d\u00e9tail\u00a0:<\/p>\n

TDD\u00a0: d\u00e9veloppement pilot\u00e9 par les tests<\/strong><\/p>\n

Le d\u00e9veloppement pilot\u00e9 par les<\/a>\u00a0\u00a0tests (TDD) est un processus de d\u00e9veloppement logiciel qui repose sur la transformation des exigences logicielles en cas de test avant que le logiciel ne soit enti\u00e8rement d\u00e9velopp\u00e9, et sur le suivi de tout le d\u00e9veloppement logiciel en testant \u00e0 plusieurs reprises le logiciel pour tous les cas de test.\u00a0C’est le contraire de d\u00e9velopper d’abord un logiciel, puis de cr\u00e9er des cas de test.\u00a0Certains mod\u00e8les populaires prennent tr\u00e8s bien en charge TDD, tels que MVC et\u00a0\u00a0MVP<\/a>\u00a0.<\/p>\n

<\/figure>\n

BDD\u00a0: D\u00e9veloppement ax\u00e9 sur le comportement (Behavior Driven Development)<\/strong><\/p>\n

Le d\u00e9veloppement pilot\u00e9 par le comportement (BDD) est \u00e9galement un processus de d\u00e9veloppement logiciel agile.\u00a0Il encourage la collaboration entre les d\u00e9veloppeurs, les testeurs d’assurance qualit\u00e9 et les repr\u00e9sentants des clients dans les projets logiciels.\u00a0Il encourage les \u00e9quipes \u00e0 utiliser des conversations et des exemples concrets pour formaliser une compr\u00e9hension commune du fonctionnement de l’application.\u00a0Il vient du d\u00e9veloppement pilot\u00e9 par les tests (TDD).<\/p>\n

<\/figure>\n

ATDD\u00a0: d\u00e9veloppement pilot\u00e9 par les tests d’acceptation<\/strong><\/p>\n

Afin de promouvoir la r\u00e9alisation de code fonctionnel par le biais de cas de tests unitaires, l’\u00e9quipe doit d\u00e9finir les normes de qualit\u00e9 et les r\u00e8gles d’acceptation attendues, et promouvoir la pratique TDD des d\u00e9veloppeurs et les performances des testeurs gr\u00e2ce \u00e0 un plan de test d’acceptation clair et coh\u00e9rent (comprenant une s\u00e9rie de tests sc\u00e9narios).\u00a0Pour les d\u00e9veloppeurs, il met l’accent sur la mani\u00e8re de mettre en \u0153uvre le syst\u00e8me et de le tester.<\/p>\n

<\/figure>\n

DDD\u00a0: Conception de lecteur de domaine<\/strong><\/p>\n

DDD fait r\u00e9f\u00e9rence \u00e0 la conception pilot\u00e9e par le domaine, c’est-\u00e0-dire au d\u00e9veloppement pilot\u00e9 par le domaine.\u00a0DDD est en fait construit sur cette base car il se concentre sur la conception de la couche de service, se concentre sur la mise en \u0153uvre commerciale, combine l’analyse et la conception, et ne le maintient plus dans un \u00e9tat divis\u00e9, afin de mettre en \u0153uvre correctement et compl\u00e8tement les besoins des clients et de construire un mod\u00e8le d’entreprise. \u00e9volutivit\u00e9.<\/p>\n

<\/figure>\n

Plan de mise en \u0153uvre du TDD<\/span><\/h3>\n

Gr\u00e2ce \u00e0 des tests pour promouvoir l’ensemble du d\u00e9veloppement, mais le d\u00e9veloppement pilot\u00e9 par les tests n’est pas simplement un simple travail de test, mais un processus de quantification de l’analyse des exigences, de la conception et du contr\u00f4le de la qualit\u00e9.<\/em><\/p><\/blockquote>\n

Principes de d\u00e9veloppement<\/strong><\/p>\n

\u00c9crivez d’abord le code de test, puis \u00e9crivez le code de la fonction.<\/em><\/p><\/blockquote>\n

    \n
  1. \u00c9crire le code de test conform\u00e9ment au document d’exigences, et non pour r\u00e9aliser la fonction\u00a0;<\/li>\n
  2. Je ne veux pas grossir d’une bouch\u00e9e.\u00a0Lorsque vous testez de grands blocs fonctionnels, vous devez d’abord les diviser en blocs fonctionnels plus petits pour les tests\u00a0;<\/li>\n
  3. N’oubliez pas de ne pas \u00e9crire de code pour compl\u00e9ter la fonction, utilisez le code le plus simple possible pour impl\u00e9menter la fonction\u00a0;<\/li>\n
  4. Si les exigences peuvent \u00eatre test\u00e9es, \u00e9crivez du code de test et abandonnez celles qui ne peuvent pas \u00eatre test\u00e9es ou pensez qu’elles n’ont pas besoin d’\u00eatre test\u00e9es\u00a0;<\/li>\n
  5. Avant de modifier\/d’ajouter un code de fonction, vous devez d’abord d\u00e9terminer si vous souhaitez modifier\/ajouter des cas de test\u00a0;<\/li>\n
  6. Code de fonction\/test, structure d\u00e9raisonnable, code en double, etc., refactoriser dans le temps apr\u00e8s la r\u00e9ussite du test.<\/li>\n<\/ol>\n

    Processus de d\u00e9veloppement TDD<\/strong><\/p>\n

      \n
    1. Analyser et d\u00e9terminer un sc\u00e9nario de test cible\u00a0;<\/li>\n
    2. Ajouter un test unitaire pour v\u00e9rifier l’entr\u00e9e et la sortie du sc\u00e9nario de test\u00a0;<\/li>\n
    3. Ex\u00e9cutez le test et obtenez le r\u00e9sultat du test d’\u00e9chec\u00a0;<\/li>\n
    4. \u00c9crivez le code de fonction le plus simple pour r\u00e9ussir le test\u00a0;<\/li>\n
    5. Ex\u00e9cutez \u00e0 nouveau le test et v\u00e9rifiez que le test r\u00e9ussit\u00a0;<\/li>\n
    6. Effectuer la refactorisation du code, y compris le code fonctionnel et le code de test unitaire\u00a0;<\/li>\n
    7. R\u00e9p\u00e9tez les \u00e9tapes ci-dessus jusqu’\u00e0 ce que le d\u00e9veloppement soit termin\u00e9.<\/li>\n<\/ol>\n

      Avantages du TDD<\/strong><\/p>\n

        \n
      1. R\u00e9duisez la charge des d\u00e9veloppeurs<\/strong>\u00a0.\u00a0Gr\u00e2ce \u00e0 un processus clair, concentrons-nous sur un seul point \u00e0 la fois, et le fardeau de la r\u00e9flexion est moindre.<\/li>\n
      2. Le filet de protection<\/strong>\u00a0.\u00a0La couverture des tests unitaires complets fournit un filet de protection pour le code produit, ce qui permet de r\u00e9pondre facilement aux changements d’exigences ou d’am\u00e9liorer la conception du code.\u00a0Ainsi, si les exigences de votre projet sont stables, r\u00e9alis\u00e9es en une fois et qu’il n’y a pas de modifications ult\u00e9rieures, les avantages de TDD sont moindres.<\/li>\n
      3. Clarifier les exigences \u00e0 l’avance<\/strong>\u00a0.\u00a0R\u00e9diger des tests en premier peut nous aider \u00e0 r\u00e9fl\u00e9chir aux exigences et \u00e0 clarifier les d\u00e9tails des exigences \u00e0 l’avance, plut\u00f4t que de d\u00e9couvrir des exigences peu claires seulement \u00e0 mi-parcours du code.<\/li>\n
      4. R\u00e9troaction rapide<\/strong>\u00a0.\u00a0Beaucoup de gens disent que lorsque TDD, mon volume de code augmente, donc l’efficacit\u00e9 du d\u00e9veloppement diminue.\u00a0Cependant, si vous n’avez pas de tests unitaires, vous devez les tester manuellement, vous passez beaucoup de temps \u00e0 pr\u00e9parer des donn\u00e9es, \u00e0 lancer des applications, \u00e0 modifier des interfaces, etc., et les retours sont lents.\u00a0<\/span>Pour \u00eatre pr\u00e9cis, un retour rapide est un avantage des tests unitaires.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
        \n
        \n
        \n<\/div>\n
        \n
        \n

        Principes agiles et Scrum<\/span><\/h4>\n