Qu’est-ce que le Test-Driven Development ?
Avec le TDD, les tests unitaires automatisés sont écrits avant le code, contrairement à la pratique traditionnelle qui consiste à écrire le code puis les tests. Des études montrent que le TDD réduit la densité des défauts en production de 40 à 80 %.
On trouve de nombreux articles et livres sur le sujet, mais le TDD se résume en quelques étapes rapides :
- Écrivez le test automatisé. Il doit couvrir uniquement la fonction à implémenter.
- Lancez le test et vérifiez qu’il échoue. Il doit échouer, car le code n’existe pas encore. Sinon, réécrivez le test.
- Écrivez le code. Juste assez pour que le test passe.
- Relancez le test. S’il passe, passez à l’étape suivante. Sinon, modifiez le code et retestez.
- Refactorez le code. Pour améliorer la conception, si besoin.
- Répétez. Passez à la prochaine fonctionnalité.
On voit vite comment cela peut rallonger le développement.
Qu’est-ce qu’une revue de code ?
La revue de code consiste à faire relire le code par un ou plusieurs développeurs pour s’assurer que les exigences sont respectées et détecter d’éventuelles erreurs ou problèmes de conception.
La forme la plus courante est la revue « au-dessus de l’épaule », où les développeurs passent le code ensemble, en personne ou à distance. Mais ces revues peuvent aussi se faire par email ou en pair programming.
Comme le TDD, la revue de code prend du temps. On mobilise d’autres développeurs – souvent seniors – pour relire au lieu de coder.
Les coûts directs d’ignorer le TDD et les revues de code
Écrire du code est un acte humain : il faut interpréter les exigences, puis écrire les lignes qui les réalisent. Comme toute activité humaine, des erreurs surviennent. Les défauts font partie du développement logiciel.
Mais le moment où l’on détecte ces défauts, et la rapidité pour les corriger, sont cruciaux. Plus un bug est détecté tôt dans le cycle de vie logiciel (SDLC), moins il coûte à corriger. On estime qu’un bug corrigé en production coûte 100 fois plus qu’un bug trouvé en conception.
Un défaut à 50 $ en développement peut coûter jusqu’à 5 000 $ après livraison. Ce chiffre paraît énorme, mais il s’explique facilement :
Prenons un scénario simple : une développeuse détecte un bug grâce au TDD. Elle est immergée dans le code et la demande. Après quelques refactorings, le test passe. Temps total : 15 minutes.
Voyons maintenant tout ce qui s’ajoute pour un bug trouvé en production :
- Coût du support client : Le bug est signalé au support, qui doit vérifier, créer un ticket, parfois proposer un contournement, et répondre à chaque client concerné.
- Coût de l’interruption : Le développeur n’a pas touché ce code depuis des semaines ou des mois. Il doit se replonger dedans, ou un nouveau doit s’en charger.
- Coût de l’intégration : Il faut fusionner le correctif dans la branche principale, avec tous les risques que cela comporte.
- Coût du QA : L’équipe QA doit tester le correctif, parfois sur un périmètre large.
- Coût de la livraison : Un bug critique peut nécessiter un patch pour des dizaines ou centaines de clients.
Quand on additionne tout, on arrive vite à 2-3 heures/personne pour corriger. Multipliez par le nombre de bugs, et l’addition est salée.
Les coûts business d’ignorer le TDD et les revues de code
Les bugs trouvés en conception ou en développement restent internes. Mais une fois en production, tout change.
Aucun CEO ou CTO ne veut recevoir un appel furieux d’un client majeur à cause d’un bug. Ce n’est jamais agréable.
Aujourd’hui, tout est noté. Quelques avis à une ou deux étoiles peuvent faire très mal. La réputation de « logiciel bogué » nuit aux ventes et aux renouvellements.
Et il ne faut pas négliger la tension interne créée par les bugs en production. Cela stresse les équipes support, met la pression sur les développeurs, et désorganise tout le planning. Stress et panique mènent à d’autres erreurs et à du turnover inutile.
Les bénéfices à long terme
Le TDD et les revues de code rallongent la phase de conception, c’est un fait.
Mais le coût d’ignorer ces bonnes pratiques s’accumule vite et peut avoir des effets dévastateurs et durables.
Mettre en place le TDD et les revues de code, c’est surtout instaurer une culture où ces pratiques sont encouragées et attendues. Le soutien doit venir du sommet et être relayé à tous les niveaux.
Cela finit par faire partie de l’ADN de l’entreprise, qui devient synonyme de qualité.
Contactez INGENO pour découvrir comment accélérer le développement cloud-native de vos applications.