{"id":588,"date":"2026-02-23T16:32:54","date_gmt":"2026-02-23T15:32:54","guid":{"rendered":"https:\/\/buildmytech.fr\/?p=588"},"modified":"2026-02-25T10:13:26","modified_gmt":"2026-02-25T09:13:26","slug":"tdd-de-la-theorie-a-la-pratique","status":"publish","type":"post","link":"https:\/\/buildmytech.fr\/index.php\/2026\/02\/23\/tdd-de-la-theorie-a-la-pratique\/","title":{"rendered":"TDD de la th\u00e9orie \u00e0 la pratique"},"content":{"rendered":"\r\n

Une grosse partie des projets informatiques finissent par \u00eatre consid\u00e9r\u00e9e comme des \u00e9checs<\/strong><\/span>. Certaines raisons peuvent \u00eatre dues \u00e0 des probl\u00e8mes concernant la partie fonctionnelle ou manag\u00e9riale du projet (un projet mal d\u00e9fini, micro management\u2026).
D\u2019autres raisons comme la mauvaise qualit\u00e9 du code<\/span><\/strong> produit par les d\u00e9veloppeurs peuvent expliquer aussi ces fiascos. Par exemple, au fur et \u00e0 mesure que le produit se d\u00e9veloppe, le code change entra\u00eenant de plus en plus de bugs. Ces derniers ralentissent le d\u00e9veloppement et rendent m\u00e9contents les clients finaux.<\/p>\r\n\r\n\r\n\r\n

Quand les \u00e9quipes sont conscientes de ces risques et veulent les minimiser au maximum elles mettent en place une politique de tests<\/strong><\/span>. Ils le font pour contr\u00f4ler le comportement de leur code et ainsi diminuer le nombre de bugs.<\/p>\r\n\r\n\r\n\r\n

Cependant ,on se rend compte que la mise en place d\u2019une politique de tests automatiques dans une \u00e9quipe non exp\u00e9riment\u00e9e sur ce sujet est rarement une promenade de sant\u00e9. A cause de ces difficult\u00e9s certaines \u00e9quipes ou personnes peuvent abandonner<\/span> <\/strong>la mise en place de cette strat\u00e9gie.<\/p>\r\n\r\n\r\n\r\n

J\u2019ai donc d\u00e9cid\u00e9 d\u2019\u00e9crire un article pour aider<\/span> <\/strong>les ing\u00e9nieurs qui souhaitent mettre en place des tests automatis\u00e9s dans leurs projets informatiques. Pour plus d\u2019efficacit\u00e9, je vais partir sur un cas concret rencontr\u00e9 lors du d\u00e9veloppement de mon projet actuel.<\/p>\r\n\r\n\r\n\r\n

Avant d\u2019aller plus loin, je souhaite expliquer pourquoi faire des tests automatis\u00e9s est un tr\u00e8s bon moyen pour d\u00e9velopper rapidement en minimisant le risque de bugs.<\/p>\r\n\r\n\r\n\r\n

Pourquoi faire des tests?<\/h1>\r\n\r\n\r\n\r\n

A quoi \u00e7a sert?<\/h2>\r\n\r\n\r\n\r\n

Le r\u00f4le principal d\u2019un test est de valider un comportement<\/span><\/strong>. Ce dernier doit \u00eatre valide aujourd\u2019hui, dans un mois ou apr\u00e8s des centaines de modifications de votre code.<\/p>\r\n\r\n\r\n\r\n

Pourquoi est-ce utile?<\/h2>\r\n\r\n\r\n\r\n

N\u2019\u00e9tant pas omniscient, il y a de gros risques<\/strong> <\/span>que lors d\u2019une modification future, vous cassiez le comportement d\u2019une fonctionnalit\u00e9. Si vous ne vous en rendez pas compte, vos utilisateurs risquent de le voir. Le co\u00fbt<\/span><\/strong> de la correction sera alors d\u00e9multipli\u00e9. Plus une erreur prend du temps \u00e0 \u00eatre d\u00e9tect\u00e9e plus elle co\u00fbte ch\u00e8re<\/strong><\/span>. Il est plus facile de modifier le code qui vient d\u2019\u00eatre \u00e9crit que celui qui a \u00e9t\u00e9 fait y a trois mois dont vous ne vous souvenez plus et qui vous obligera \u00e0 faire une mise en production risqu\u00e9e<\/span><\/strong>.<\/p>\r\n\r\n\r\n\r\n

Quand vous travaillez en \u00e9quipe, vos coll\u00e8gues ne connaissent pas forc\u00e9ment tout le code applicatif. Une de leur modification peut casser le comportement que vous avez d\u00e9velopp\u00e9 il y a quelques mois.<\/p>\r\n\r\n\r\n\r\n

Les tests vont permettre d\u2019\u00e9viter ces probl\u00e8mes.<\/p>\r\n\r\n\r\n\r\n

Meilleure focalisation<\/h2>\r\n\r\n\r\n\r\n

En faisant des tests vous allez vous rendre compte que vous avez d\u00e9velopp\u00e9 une meilleure focalisation<\/span> <\/strong>avec ces quelques avantages :<\/p>\r\n\r\n\r\n\r\n

\"\"<\/figure>\r\n\r\n\r\n\r\n

 <\/p>\r\n\r\n\r\n\r\n

 <\/p>\r\n\r\n\r\n\r\n

 <\/p>\r\n\r\n\r\n\r\n

Effets secondaires positifs<\/h2>\r\n\r\n\r\n\r\n

En \u00e9crivant des tests unitaires, vous allez vous rendre compte que vous allez devoir \u00e9crire du code en respectant les principes du Clean Code<\/strong><\/span><\/a>.
Pourquoi\u00a0?<\/p>\r\n\r\n\r\n\r\n

Il est plus facile<\/strong> <\/span>de tester une classe courte<\/span> <\/strong>et focus sur un r\u00f4le qu\u2019une classe faisant 400 lignes avec plein de responsabilit\u00e9s. De plus en faisant des tests unitaires vous allez devoir isoler<\/span> <\/strong>certaines parties de votre programme qui appelle par exemple des ressources ext\u00e9rieures (bases de donn\u00e9es, url, fichiers\u2026).<\/p>\r\n\r\n\r\n\r\n

Sans vous en rendre compte, votre code produit va \u00eatre de plus en plus maintenable<\/span><\/strong>.<\/p>\r\n\r\n\r\n\r\n

 <\/p>\r\n\r\n\r\n\r\n

Maintenant que les raisons de l\u2019importance de la pratique du TDD vous ont \u00e9t\u00e9 partag\u00e9es, je vous propose de vous pr\u00e9senter l\u2019application et sa feature qui serviront \u00e0 illustrer la mise en place de cette pratique de d\u00e9veloppement. <\/em><\/p>\r\n\r\n\r\n\r\n

 <\/p>\r\n\r\n\r\n\r\n

ElectionScenario\u00a0: l\u2019API en d\u00e9veloppement<\/h1>\r\n\r\n\r\n\r\n

Rapide rappel sur le projet en d\u00e9veloppement<\/h2>\r\n\r\n\r\n\r\n

En parall\u00e8le des articles de blog, je d\u00e9veloppe un simulateur d\u2019\u00e9lections l\u00e9gislatives<\/span><\/strong> \u00e0 partir des r\u00e9sultats des \u00e9lections 2022 et 2024 compos\u00e9s de plusieurs applications.<\/p>\r\n\r\n\r\n\r\n

Actuellement, je travaille sur l\u2019API qui servira de back au futur front.<\/p>\r\n\r\n\r\n\r\n

Ces simulations se basent sur une des trois r\u00e8gles de scrutins expliqu\u00e9s pr\u00e9c\u00e9demment<\/span>\u00a0<\/strong><\/a>:<\/p>\r\n\r\n\r\n\r\n

    \r\n
  1. Majorit\u00e9 \u00e0 un tour<\/li>\r\n\r\n\r\n\r\n
  2. Proportionnelle nationale<\/li>\r\n\r\n\r\n\r\n
  3. Proportionnelle d\u00e9partementale<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

    L\u2019impl\u00e9mentation de la troisi\u00e8me r\u00e8gle est la feature qui va \u00eatre utilis\u00e9e dans cet article pour illustrer le d\u00e9veloppement en TDD.<\/p>\r\n\r\n\r\n\r\n

    Workflow de la simulation d\u2019\u00e9lections avec la r\u00e8gle \u00ab\u00a0Proportionnelle d\u00e9partementale\u00a0\u00bb.<\/h2>\r\n\r\n\r\n\r\n\r\n\r\n

    \"\"<\/p>\r\n\r\n\r\n\r\n

    Apr\u00e8s avoir analys\u00e9 et compris ce workflow, il faut se poser la question en quoi les tests et le TDD vont m\u2019aider au d\u00e9veloppement de cette feature.<\/p>\r\n\r\n\r\n\r\n

     <\/p>\r\n\r\n\r\n\r\n

    Apr\u00e8s avoir vu le fonctionnel de notre feature, et compris l\u2019importance des tests unitaires, il est temps de voir comment int\u00e9grer ces derniers dans notre processus de d\u00e9veloppement dans le d\u00e9veloppement de notre feature.<\/em><\/p>\r\n\r\n\r\n\r\n

    Comment faire?<\/h1>\r\n\r\n\r\n\r\n

    Vous venez de prendre la d\u00e9cision que vous voulez faire des tests unitaires. Je vous en f\u00e9licite, c\u2019est une tr\u00e8s bonne nouvelle. Comme vous ne savez pas par o\u00f9 commencer, je vous propose de continuer \u00e0 lire cet article pour avoir un exemple de programme d\u00e9velopp\u00e9 avec des tests.<\/p>\r\n\r\n\r\n\r\n

    Padawan des tests<\/h2>\r\n\r\n\r\n\r\n

    D\u2019abord, renseignez-vous<\/span><\/strong> exactement sur les d\u00e9finitions des termes suivants\u00a0:<\/p>\r\n\r\n\r\n\r\n

      \r\n
    1. Les tests unitaires<\/a><\/span><\/li>\r\n\r\n\r\n\r\n
    2. La pyramide des tests<\/a><\/span><\/li>\r\n\r\n\r\n\r\n
    3. Le TDD<\/span><\/a><\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n\r\n\r\n

      Pour commencer le d\u00e9veloppement TDD<\/span> <\/strong>et vos premiers tests unitaires en \u00e9tant d\u00e9butant je vous donne deux conseils\u00a0:<\/p>\r\n\r\n\r\n\r\n

        \r\n
      1. Faites-vous accompagner par un senior<\/span><\/strong> sachant faire des tests unitaires et d\u00e9velopper en TDD. Il vous vulgarisera les concepts, vous fera gagner du temps d\u2019apprentissage et vous corrigera en cas d\u2019erreur.<\/li>\r\n\r\n\r\n\r\n
      2. Pour vos premiers essais commencez pendant votre temps libre ou au travail si vous pouvez faire de la veille technique, en faisant des Katas<\/span> <\/a>(https:\/\/codingdojo.org\/kata\/<\/a>). Ce sont des petits exercices<\/span> <\/strong>pouvant \u00eatre r\u00e9alis\u00e9s en TDD. Puis apr\u00e8s avoir fait plusieurs katas, il va falloir utiliser le TDD <\/span>et les Tests unitaires dans le d\u00e9veloppement de vrais projets<\/span><\/strong>. Vous pouvez soit le faire sur vos projets pros<\/span> <\/strong>ou soit sur vos projets persos avec un enjeu business<\/span> <\/strong>ou fonctionnel<\/span><\/strong>.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

        Pour ma part j\u2019ai plus ou moins utilis\u00e9 les deux m\u00e9thodes pour acqu\u00e9rir de l\u2019exp\u00e9rience sur le TDD et les tests unitaires. J\u2019ai commenc\u00e9 par m\u2019auto former puis ma fa\u00e7on de faire a \u00e9volu\u00e9 gr\u00e2ce aux \u00e9changes avec des gens plus seniors que moi sur le sujet et par l\u2019exp\u00e9rimentation sur mes projets, pros et persos.<\/p>\r\n\r\n\r\n\r\n

        Comment faire du TDD?<\/h2>\r\n\r\n\r\n\r\n

        Dans la partie 2, je vous ai d\u00e9crit la nouvelle feature \u00e0 d\u00e9velopper. Elle est compos\u00e9e de plusieurs sous features<\/strong><\/span>. Si je veux r\u00e9aliser son d\u00e9veloppement comment je fais ? Est-ce que je d\u00e9veloppe en TDD en premier les sous-features et apr\u00e8s, je fais la classe qui les appelle ou je commence par le haut pour ensuite faire les d\u00e9veloppements secondaires ?<\/p>\r\n\r\n\r\n\r\n

        Pour r\u00e9pondre \u00e0 ces questions, je vais vous pr\u00e9senter trois fa\u00e7ons dont vous pouvez coder les tests.<\/p>\r\n\r\n\r\n\r\n

        Inside Out<\/h3>\r\n\r\n\r\n\r\n

        Votre but est de commencer par d\u00e9velopper des features ou des sous features ind\u00e9pendantes<\/span><\/strong>. Vous ne pouvez pas commencer par quelque chose qui appelle une autre fonction ou classe qui n\u2019a pas \u00e9t\u00e9 programm\u00e9e en TDD.<\/p>\r\n\r\n\r\n\r\n

        Si on reprend l\u2019exemple au-dessus, vous pouvez d\u00e9velopper la feature 2 si ses sous features (a, b, c\u2026) ont \u00e9t\u00e9 d\u00e9velopp\u00e9es en TDD avant.<\/p>\r\n\r\n\r\n\r\n

        Pour vous aider voil\u00e0 un sch\u00e9ma qui va vous aider pour comprendre l\u2019ordre de d\u00e9veloppement de toutes les features.<\/p>\r\n\r\n\r\n\r\n

        \"\"<\/figure>\r\n\r\n\r\n\r\n

         <\/p>\r\n\r\n\r\n\r\n

        Comme le montre le sch\u00e9ma, on commence soit par une fonctionnalit\u00e9 qui n\u2019a pas de sous-fonctionnalit\u00e9s ou soit par des sous-features ind\u00e9pendantes en terminant par celles qui sont d\u00e9pendantes.<\/p>\r\n\r\n\r\n\r\n

        Est-ce que cette m\u00e9thode est ultime\u00a0? Non. Voici un tableau qui selon moi expose ses points forts et faibles<\/p>\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
        Avantages<\/strong><\/td>\r\nInconv\u00e9nients<\/strong><\/td>\r\n<\/tr>\r\n
        Si un test est KO, on sait rapidement o\u00f9 l\u2019erreur a eu lieu et quoi d\u2019\u00eatre corrig\u00e9<\/td>\r\nOn ne teste pas forc\u00e9ment, correctement le workflow complet de la feature<\/td>\r\n<\/tr>\r\n
        Facile \u00e0 tester les cas exceptionnels, car on peut le faire l\u00e0 o\u00f9 ils se produisent.<\/td>\r\nComme on commence par des petites features, on peut facilement se perdre dans le d\u00e9veloppement et d\u00e9velopper des sous features qui ne seront pas utilis\u00e9s ult\u00e9rieurement.<\/td>\r\n<\/tr>\r\n
        Petits tests faciles \u00e0 comprendre<\/td>\r\nMultiplication des tests unitaires<\/td>\r\n<\/tr>\r\n
        \u00a0<\/td>\r\nSi le code change et non le fonctionnement, on doit reprendre les tests.<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/figure>\r\n\r\n\r\n\r\n\r\n\r\n

         <\/p>\r\n\r\n

        Outside In<\/h3>\r\n

        Ici, on va plus se concentrer par tester la feature principale<\/span><\/strong> et non sur les sous features. Pourquoi ? Comme la feature principale appelle les sous features, si ses tests sont verts \u00e7a veut dire que toutes les sous features fonctionnent correctement.<\/p>\r\n

         <\/p>\r\n

        \"\"<\/p>\r\n

         <\/p>\r\n

        D\u2019abord, on d\u00e9veloppe le cas passant<\/span> <\/strong>de la feature principale. Ensuite, on travaille sur la feature principale, puis ses sous features et \u2026 jusqu\u2019\u00e0 ce que tout soit d\u00e9velopp\u00e9.<\/p>\r\n

        Quand on a termin\u00e9 de d\u00e9velopper le cas passant, on cr\u00e9e<\/span> de nouveaux tests pour ajouter de nouveaux cas fonctionnels. Ainsi, on modifie tout le code produit pour r\u00e9pondre \u00e0 tous les cas<\/strong><\/span>.<\/p>\r\n

        Quand vous d\u00e9veloppez la feature principale vous n\u2019allez pas forc\u00e9ment cr\u00e9er les futures classes qui vont \u00eatre cod\u00e9es pour les sous features. Vous pouvez cr\u00e9er du code qui renverra des donn\u00e9es \u00ab faites \u00e0 la main \u00bb. Plus tard quand la sous-feature sera termin\u00e9e, vous utiliserez le code qui appelle<\/span> <\/strong>la sous-feature.<\/p>\r\n

        Selon moi voici un tableau r\u00e9sumant les avantages et les d\u00e9savantages de cette solution.<\/p>\r\n

        \r\n\r\n<\/p>\r\n

        \r\n\r\n\r\n\r\n\r\n\r\n\r\n
        Avantages<\/strong><\/td>\r\nInconv\u00e9nients<\/strong><\/td>\r\n<\/tr>\r\n
        Tests plus fonctionnels donc si le code change peu d\u2019impact voir aucun sur les tests<\/td>\r\nEn cas de tests KO, vous mettrez du temps \u00e0 trouver o\u00f9 est l\u2019erreur comme vous ne tester pas toutes les sous-classes<\/td>\r\n<\/tr>\r\n
        Workflow test\u00e9<\/td>\r\nVos tests peu nombreux risquent d\u2019\u00eatre volumineux et longs \u00e0 \u00e9crire, car vous devrez couvrir \u00e0 un seul endroit tous les cas.<\/td>\r\n<\/tr>\r\n
        On ne d\u00e9veloppe pas des features inutiles<\/td>\r\n\u00a0<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/figure>\r\n\r\n

         <\/p>\r\n\r\n

        Troisi\u00e8me solution : double loop TDD<\/h3>\r\n

        Chaque fa\u00e7on de faire poss\u00e8de des avantages et des inconv\u00e9nients comme le montre les tableaux.<\/p>\r\n

        Comment faire pour trouver une m\u00e9thode qui allie les avantages du inside out et du outside in ? En faisant le double loop TDD<\/span><\/strong> comme le montre ce workflow:<\/p>\r\n

        \"\"<\/p>\r\n

        Comme on peut le voir dans cette m\u00e9thode, on commence par le test de la feature principale puis on d\u00e9veloppe cette derni\u00e8re. Ensuite, on se met \u00e0 coder en TDD la feature 1, puis la 2 \u2026.<\/p>\r\n

        Dans ce cas, les diff\u00e9rents cas \u00e0 tester ne seront pas contenus dans les tests de la feature principale, mais dans les tests de la feature concern\u00e9s par ces diff\u00e9rents cas.<\/p>\r\n

        Voici un tableau illustrant les avantages et les inconv\u00e9nients de cette m\u00e9thode :<\/p>\r\n

        \r\n\r\n<\/p>\r\n

        \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
        Avantages<\/strong><\/td>\r\nInconv\u00e9nients<\/strong><\/td>\r\n<\/tr>\r\n
        Si un test est KO, on sait rapidement o\u00f9 l\u2019erreur a eu lieu et quoi d\u2019\u00eatre corrig\u00e9e<\/td>\r\nBeaucoup de tests \u00e0 \u00e9crire<\/td>\r\n<\/tr>\r\n
        Facile \u00e0 tester les cas exceptionnels, car on peut le faire l\u00e0 o\u00f9 ils se produisent.<\/td>\r\nSi le code change et non le fonctionnement, on doit modifier les tests<\/td>\r\n<\/tr>\r\n
        Petits tests faciles \u00e0 comprendre<\/td>\r\n\u00a0<\/td>\r\n<\/tr>\r\n
        Workflow test\u00e9<\/td>\r\n\u00a0<\/td>\r\n<\/tr>\r\n
        On ne d\u00e9veloppe pas de features inutiles<\/td>\r\n\u00a0<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/figure>\r\n

        <\/p>\r\n\r\n

         <\/p>\r\n\r\n

        Et moi qu'est ce que j'en pense et qu'est ce que je choisis?<\/h3>\r\n

        Dans mon apprentissage des tests, j\u2019ai commenc\u00e9 par le Inside Out. Cependant, j\u2019ai eu de gros probl\u00e8mes :<\/p>\r\n

          \r\n
        1. J\u2019avais beaucoup de bugs \u00e0 corriger quand je d\u00e9veloppais le workflow qui allait orchestrer<\/span> <\/strong>toutes les fonctionnalit\u00e9s cod\u00e9es.<\/li>\r\n
        2. Je d\u00e9veloppais de features inutiles, car je me concentrais d\u2019abord sur une feature isol\u00e9e sans savoir si elle sera utilis\u00e9e dans le worflow final.<\/li>\r\n<\/ol>\r\n

          Je ne suis pas assez convaincu par la solution 2. Pour moi, il est important de comprendre rapidement pourquoi un test est KO. Si ce dernier appelle la terre enti\u00e8re, vous allez mettre du temps \u00e0 le corriger.<\/p>\r\n

          J\u2019utilise la solution 3 depuis plusieurs mois. Je la trouve super m\u00eame si je me rends compte qu\u2019elle prend du temps et qu\u2019elle est verbeuse.<\/p>\r\n

          Peut-\u00eatre que dans un projet futur, je partirai uniquement sur la solution 2 pour challenger mon avis.<\/p>\r\n

          Apr\u00e8s avoir expliqu\u00e9 pourquoi il faut faire des tests, quelles features allaient \u00eatre d\u00e9velopp\u00e9s et quelles fa\u00e7ons d\u2019\u00e9crire allaient \u00eatre choisis, il nous manque plus qu\u2019\u00e0 commencer \u00e0 d\u00e9velopper notre feature en TDD.<\/em><\/p>\r\n

          Mise en pratique<\/h1>\r\n

          Il est de temps d\u2019utiliser le TDD pour d\u00e9velopper nos propres features. Je vous propose de mettre en pratique en partant sur la fonctionnalit\u00e9 2\u00a0:<\/p>\r\n

          \u00ab\u00c0 partir des donn\u00e9es r\u00e9cup\u00e9r\u00e9es, on va parcourir chaque d\u00e9partement fran\u00e7ais pour faire plusieurs t\u00e2ches permettant de trouver les \u00e9lus. \u00bb<\/p>\r\n

          Voici le workflow de d\u00e9veloppement\u00a0:<\/p>\r\n

          1 - Cr\u00e9er le squelette de la classe et de sa m\u00e9thode principale<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

          2 - Cr\u00e9er le premier test sans le r\u00e9soudre.<\/p>\r\n


          \"\"Comme vous pouvez le voir, le test est KO.\u00a0\u00a0<\/p>\r\n

          3 - Maintenant, il faut r\u00e9soudre ce test de la mani\u00e8re la plus simple possible. Pour se faire, on va \u00e9crire du code en dur.<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

          Comme on peut le voir le test est r\u00e9solu.<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

          4 - Comme on le voit dans la partie 2, cette fonctionnalit\u00e9 poss\u00e8de des sous-fonctionnalit\u00e9s. Maintenant, on va commencer par le d\u00e9veloppement de la sous-feature \u00ab On compte combien de d\u00e9put\u00e9s poss\u00e8de ce d\u00e9partement \u00bb. Elle sera d\u00e9velopp\u00e9e dans la classe \u00ab GetCandidatesByDepartmentGroupedByDistrict<\/strong><\/span>.<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

          5 - Maintenant, on va d\u00e9velopper le premier test qui sera bien sur KO<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

          6 - Nous partons sur uniquement un seul test, car les cas d\u2019utilisations de cette classe ne varient pas. On peut donc \u00e9crire le code qui va r\u00e9soudre ce test :<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

           <\/p>\r\n

          Puis on relance les tests et on voit que tout fonctionne.<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

          7 - Maintenant on va faire la m\u00eame chose pour toutes les autres sous-fonctionnalit\u00e9s. Apr\u00e8s les avoir d\u00e9velopp\u00e9es et les avoir faites appel\u00e9es par la classe CongressPersonByDepartment<\/span> <\/strong>permettant de faire fonctionner la feature principale, le code final de la feature ressemble \u00e0 \u00e7a :<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

          Pour \u00eatre s\u00fbr que tout soit couvert, on a \u00e9crit plusieurs tests pour plusieurs types de d\u00e9partement :<\/p>\r\n

          \"\"<\/p>\r\n

           <\/p>\r\n

          J\u2019ai essay\u00e9 de vous montrer comment j\u2019avais d\u00e9velopp\u00e9 cette fonctionnalit\u00e9 en faisant du TDD. Ce n\u2019\u00e9tait pas parfait, mais j\u2019esp\u00e8re que ca vous aider \u00e0 vous lancer dans le d\u00e9veloppement pilot\u00e9 par les tests.<\/p>\r\n

          En faisant du TDD, vous allez avoir deux challenges\u00a0: <\/em><\/p>\r\n

            \r\n
          1. La construction de vos jeux de donn\u00e9es <\/em><\/li>\r\n
          2. La validation de vos tests <\/em><\/li>\r\n<\/ol>\r\n

            Ces deux besoins peuvent devenir rapidement verbeux, longs \u00e0 \u00e9crire et emb\u00eatant \u00e0 maintenir. Pour cela, je vous propose quelques petites astuces vous permettant d\u2019\u00eatre efficace.<\/em><\/p>\r\n

            Comment avoir des donn\u00e9es de tests rapidement et pouvoir valider efficacement nos tests\u00a0?<\/h1>\r\n

            Dans cette partie, je vous propose de vous aider pour trouver des astuces pour avoir rapidement vos donn\u00e9es \u00e0 tester et des m\u00e9thodes pour valider vos tests.<\/p>\r\n

            Les donn\u00e9es<\/h2>\r\n

            Quand on apprend le TDD, on vous montre des tests assez simples. Ils valident une valeur ou un objet simple. Cependant, en r\u00e9alit\u00e9 vous allez devoir faire des tests sur des objets complexes.<\/p>\r\n

            Dans mon projet par exemple, quand je veux tester la simulation d\u2019une \u00e9lection en mode proportionnelle d\u00e9partementale, j\u2019ai besoin d\u2019un objet \u00ab election_result \u00bb constitu\u00e9s d\u2019une multitude de sous-objets comme on le voit ci-dessous :<\/p>\r\n

            \"\"<\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

            Si je devais cr\u00e9er cet objet \u00e0 la main, cela me prendrait beaucoup de temps et d\u2019\u00e9nergie. Il faut trouver un moyen pour avoir la possibilit\u00e9 de cr\u00e9er des objets complexes utilisables assez rapidement.<\/p>\r\n

            JSON<\/h2>\r\n

            En utilisant la d\u00e9serialisation JSON<\/span><\/strong>, on peut facilement cr\u00e9er des objets complexes pour nos tests.<\/p>\r\n

            Tout d\u2019abord on cr\u00e9\u00e9 notre objet JSON en s\u2019aidant de ce site super pratique JsonFormatter<\/a><\/strong><\/span>.<\/p>\r\n

            \"\"<\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

            Puis il suffit de minifier ce JSON comme le site Jsonformatter<\/strong> <\/span>permet de le faire. On stocke le json minifi\u00e9 dans une variable. Il suffit de le d\u00e9serialiser dans un objet python pour pouvoir l\u2019utiliser dans nos tests comme le montre cet exemple\u00a0:<\/p>\r\n

            \"\"\"\"<\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

            Ce code est facilement modifiable pour \u00eatre r\u00e9utilisable.<\/p>\r\n

            Assert<\/h2>\r\n

            Un moment, vous allez devoir v\u00e9rifier que l\u2019objet obtenu apr\u00e8s l\u2019ex\u00e9cution de votre test correspond bien au r\u00e9sultat attendu. Si vous avez un long objet \u00e0 v\u00e9rifier, il risque de devenir volumineux.<\/p>\r\n

            \u00c0 l\u2019heure actuelle, comme je teste souvent des objets d\u2019un m\u00eame type, j\u2019ai d\u00e9cid\u00e9 de cr\u00e9er des m\u00e9thodes d\u2019assertions que j\u2019appelle \u00e0 chaque test.<\/p>\r\n

            Par exemple dans le test suivant\u00a0:<\/p>\r\n

            \"\"Dans ce test, la m\u00e9thode Select<\/span> <\/strong>de la classe CongressPersonElected doit s\u00e9lectionner dans chacun des circonscriptions pass\u00e9es en param\u00e8tre le candidat \u00e9lu. La partie \u00ab\u00a0expected\u00a0\u00bb est une cha\u00eene de caract\u00e8re regroupant les donn\u00e9es du candidat \u00e9lu attendu avec pour s\u00e9parateur |.<\/p>\r\n

            Pour gagner en clart\u00e9, j\u2019ai centralis\u00e9 l\u2019assertion des CongressPerson<\/span> <\/strong>\u00e0 un seul endroit comme on le voit ci-dessous :<\/p>\r\n

            \"\"<\/p>\r\n

             <\/p>\r\n

            \"\"<\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

             <\/p>\r\n

            Cette fa\u00e7on de faire les assert n\u2019est pas la meilleure. On pourrait utiliser la serialisation JSON et comparer les deux cha\u00eenes de caract\u00e8res. Peut-\u00eatre que j\u2019utiliserai cette fa\u00e7on d\u2019asserter dans un prochain projet.<\/p>\r\n

            Gr\u00e2ce \u00e0 toutes ces am\u00e9liorations, on va gagner du temps, et rendre nos tests plus lisibles et maintenables.<\/p>\r\n

            Avant de conclure cet article, je voudrais \u00e9changer sur les limites du TDD que je pratique. M\u00eame si je trouve cela tr\u00e8s efficace et je pense que cela devrait une pratique ma\u00eetris\u00e9e et pratiqu\u00e9e par les \u00e9quipes de dev. Elle n\u2019est pas magique et poss\u00e8de aussi des d\u00e9fauts que j\u2019ai envie de vous partager.<\/em><\/p>\r\n

            Rien n\u2019est jamais parfait<\/h1>\r\n

            Si j\u2019ai bien fait mon travail, je vous ai convaincu de faire du TDD pour r\u00e9aliser vos logiciels rapidement sans bug. Comme la perfection n\u2019existe pas, il est temps de parler des d\u00e9fauts de cette m\u00e9thode.<\/p>\r\n

            Pas partout<\/h2>\r\n

            L\u2019impl\u00e9mentation et l\u2019efficacit\u00e9 du TDD d\u00e9pendent \u00e9norm\u00e9ment du contexte<\/span><\/strong>. Prenons deux exemples :<\/p>\r\n

              \r\n
            1. Embarqu\u00e9 : Si vous souhaitez l\u2019impl\u00e9menter pour ce genre de projet, vous risquez d\u2019\u00e9chouer. En effet, cette m\u00e9thode de d\u00e9veloppement n\u2019a pas \u00e9t\u00e9 pr\u00e9vu pour ce genre de projet. Je ne dis pas que c\u2019est impossible, mais c\u2019est tr\u00e8s difficile. Il va falloir trouver des solutions \u00e0 des contraintes qui n\u2019existent pas dans l\u2019informatique de gestion.<\/li>\r\n
            2. CRUD\u00a0: si votre projet est un simple CRUD<\/strong> <\/span>sans r\u00e8gle business, pourquoi faire du TDD ? G\u00e9n\u00e9ralement, dans ce genre de projet, vous avez des simples mapper et des appels \u00e0 une BDD \u00e0 d\u00e9velopper. Le faire en TDD n\u2019est pas forc\u00e9ment utile.<\/li>\r\n<\/ol>\r\n

              Bienvenue en enfer<\/h2>\r\n

              Si vous n\u2019avez pas un ego surdimensionn\u00e9 ou si vous n\u2019\u00eates pas victime du biais Effet Dunning-Kruger <\/strong><\/span><\/a>\u00a0vous allez vous rendre compte que ma\u00eetriser le TDD va vous prendre beaucoup de temps et d\u2019\u00e9nergie. Vous allez commettre des erreurs qui risquent de vous d\u00e9courager mais aussi d\u2019amoindrir l\u2019efficacit\u00e9 de cette m\u00e9thode de d\u00e9veloppement. Vous allez devoir persister dans votre progression pour voir les bienfaits<\/span> du TDD.<\/p>\r\n

              Apr\u00e8s plusieurs ann\u00e9es de pratique, je dois encore progresser pour avoir une meilleure ma\u00eetrise. Par exemple, je veux faire un projet uniquement en outside-in pour le ma\u00eetriser et me faire une meilleure id\u00e9e sur cette m\u00e9thode.<\/p>\r\n

              Si votre entreprise ne vous permet pas de le pratiquer, vous allez devoir le faire sur votre temps libre dans vos propres projets.<\/p>\r\n

              Mon conseil, soyez patients, pratiquez et petit \u00e0 petit, vous allez voir vos progr\u00e8s en devenant plus efficace.<\/p>\r\n

              Opposition<\/h2>\r\n

              Une des principales difficult\u00e9s que vous allez rencontrer va \u00eatre de convaincre<\/span> <\/strong>votre entourage professionnel d\u2019utiliser cette m\u00e9thode de d\u00e9veloppement. Vous allez vite vous rendre compte que vous allez avoir trois types d\u2019opposants\u00a0:<\/p>\r\n

                \r\n
              1. Vos coll\u00e8gues plus juniors. Comme dit juste avant, faire du TDD efficacement n\u00e9cessite du temps et de l\u2019\u00e9nergie. Pour une personne junior, l\u2019effort \u00e0 produire sera beaucoup plus important. Vous allez donc devoir les accompagner pendant leur apprentissage si vous voulez que le TDD soit bien utilis\u00e9. \u00c7a va donc vous prendre encore plus temps et d\u2019\u00e9nergie. Ils peuvent aussi s\u2019y opposer \u00e0 cause des difficult\u00e9s li\u00e9es \u00e0 l\u2019apprentissage.<\/li>\r\n
              2. Vos coll\u00e8gues pensant \u00eatre \u00ab senior \u00bb. Dans notre profession assez masculine, vous avez beaucoup de d\u00e9veloppeurs qui ont un probl\u00e8me avec leur ego<\/span><\/strong>. Ils ont besoin de se sentir bon et se surestiment beaucoup. Comme ils pensent \u00eatre les meilleurs, ils ont beaucoup de difficult\u00e9s \u00e0 se remettre en cause pour s\u2019am\u00e9liorer. Ils ne comprennent pas pourquoi il faut faire du TDD alors qu\u2019ils codent d\u00e9j\u00e0 tellement bien. Comme l\u2019apprentissage de cette m\u00e9thodologie est compliqu\u00e9e<\/span><\/strong>, s\u2019ils \u00e9prouvent de la difficult\u00e9, ils risquent de vouloir l\u00e2cher l\u2019affaire, car ils penseront que le probl\u00e8me vient du TDD et non d\u2019eux.<\/li>\r\n
              3. Vos manageurs. Quand vous n\u2019\u00eates pas un ing\u00e9nieur en d\u00e9veloppement logiciel, comprendre l\u2019int\u00e9r\u00eat du TDD peut \u00eatre compliqu\u00e9 surtout si la personne qui vous l\u2019explique n\u2019est pas un pro de la communication. Certaines personnes ont la volont\u00e9 de tout contr\u00f4ler dans leurs \u00e9quipes comme la fa\u00e7on dont travaille leurs d\u00e9veloppeurs. Comme ils auront du mal \u00e0 saisir la puissance du TDD, ils vont s\u2019y opposer, car selon eux, \u00e7a vous fera perdre du temps pour votre projet.<\/li>\r\n<\/ol>\r\n

                Si vous voulez que le TDD soit adopt\u00e9 dans votre \u00e9quipe, vous allez devoir convaincre ces trois types de profils. Comme je ne suis pas un roi de la diplomatie, je ne peux pas vous conseiller sur la fa\u00e7on de le faire. Je peux juste vous dire que montrer l\u2019exemple et la patience sont des bonnes m\u00e9thodes pour convaincre vos adversaires.<\/p>\r\n

                 <\/p>\r\n

                Il est temps de conclure cet article assez long. J\u2019esp\u00e8re que vous n\u2019\u00eates pas perdu ou assomm\u00e9 apr\u00e8s cette lecture assez intense. Je souhaite qu\u2019il aide les personnes qui veulent se lancer ou s\u2019am\u00e9liorer dans le TDD. Le meilleur conseil que je pourrai r\u00e9p\u00e9ter pour terminer est de pratiquer<\/strong> <\/span>et d\u2019\u00e9changer<\/span> <\/strong>sur votre fa\u00e7on de faire. En pratiquant, vous allez vous am\u00e9liorer et en \u00e9changeant vous allez apprendre de nouvelles fa\u00e7ons de faire.<\/p>\r\n

                Prochainement, je vous parlerai de la mise en place de l\u2019architecture hexagonale sur le back d\u2019ElectionScenario.<\/p>","protected":false},"excerpt":{"rendered":"

                Une grosse partie des projets informatiques finissent par \u00eatre consid\u00e9r\u00e9e comme des \u00e9checs. Certaines raisons peuvent \u00eatre dues \u00e0 des probl\u00e8mes concernant la partie fonctionnelle ou manag\u00e9riale du projet (un projet mal d\u00e9fini, micro management\u2026).D\u2019autres raisons comme la mauvaise qualit\u00e9 du code produit par les d\u00e9veloppeurs peuvent expliquer aussi ces fiascos. Par exemple, au fur […]<\/p>\n","protected":false},"author":1,"featured_media":589,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,9,8],"tags":[],"class_list":["post-588","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-simulationelections","category-software-craftsmanship","category-tdd"],"_links":{"self":[{"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/posts\/588","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/comments?post=588"}],"version-history":[{"count":67,"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/posts\/588\/revisions"}],"predecessor-version":[{"id":684,"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/posts\/588\/revisions\/684"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/media\/589"}],"wp:attachment":[{"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/media?parent=588"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/categories?post=588"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/buildmytech.fr\/index.php\/wp-json\/wp\/v2\/tags?post=588"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}