Bénéfices du développement piloté par les tests : Statistiques clés et études
Dans cet article, j'examine quelques statistiques et études sur le développement piloté par les tests afin de comprendre comment cette méthode est mise en œuvre, ses bénéfices, ainsi que les défis rencontrés par les équipes utilisant cette approche.
Traditionnellement, le processus de développement logiciel se déroule de façon linéaire. Cependant, ces dernières décennies, avec la popularité croissante des systèmes agiles (jusqu’à 87% des équipes suivent une approche agile ou similaire), le développement logiciel a commencé à adopter différentes méthodologies tenant compte des exigences et des caractéristiques du projet.
La technique de développement piloté par les tests (TDD) est l’une des méthodes qui attire l’attention dans le domaine du développement logiciel agile.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Dans un article de recherche publié par l'Institute of Electrical and Electronics Engineers, les auteurs Yahya Rafique et Vojislav Misic déclarent que « le Test-Driven Development (TDD) fait partie des pratiques fondamentales du processus de développement Extreme Programming (XP) » (Source).
L’homme à qui l’on attribue le développement du TDD aurait « affirmé en 2003 que le TDD encourage des conceptions simples et inspire confiance » (Source). Cependant, des questions subsistent quant aux affirmations concernant la productivité et la qualité attribuées au TDD.
Nous avons pris le temps de rassembler les statistiques les plus récentes sur le TDD afin de vérifier les affirmations avancées.
Cet article commence par définir le concept de TDD et en quoi il diffère de l’approche traditionnelle. Nous examinerons aussi certaines statistiques qui valident ou réfutent les assertions concernant le TDD.
Qu'est-ce que le développement piloté par les tests ?
Le développement piloté par les tests est une approche où un test est écrit avant que le développeur ne crée le code de production destiné à satisfaire ce test. L’idée de base de cette technique est de permettre au développeur de prendre le temps de réfléchir à son design ou à ses exigences avant d'écrire du code fonctionnel.
Processus TDD
- Écrire le test : En TDD, toutes les nouvelles fonctionnalités débutent par l’écriture d’un test. Le programmeur doit comprendre les spécifications et les exigences de la fonctionnalité. Pour ce faire, il doit examiner les user stories et cas d’utilisation afin de bien comprendre l'objectif du nouveau code à développer.
- Le test échoue : Une fois le test écrit par le programmeur, ce dernier l’exécute. Puisqu’aucun code n’existe encore pour le faire réussir, le test échouera. Cela confirme que l’environnement de test automatisé fonctionne correctement et élimine la possibilité que ce nouveau test réussisse systématiquement en raison d’un défaut.
- Écrire le code : Maintenant, le programmeur sait que la fonctionnalité fonctionne selon la conception. Il écrit alors le code qui permet de réussir le test. Le code n’est pas nécessairement parfait ni optimal, mais cela importe peu. Le développeur n’est pas censé produire du code allant au-delà de la fonctionnalité que le test entend vérifier.
- Exécuter les tests : Sachant que la fonctionnalité fonctionne comme prévu, à chaque fois qu’il publie un nouveau code, le développeur peut utiliser un outil de gestion des tests pour relancer ce test, ce qui lui offre l’assurance que la dernière modification n’a pas détérioré la fonctionnalité existante.
- Refactoriser le code : En TDD, à mesure que la base de code grandit, elle doit être nettoyée en continu. Étant donné que l’accent était mis dans les étapes précédentes sur l’écriture du strict nécessaire, cette étape vise à améliorer l’efficacité. Elle permet d’améliorer la structure interne du code source du programme, tout en maintenant ses fonctionnalités externes. On élimine les duplications et on peut ajouter de nouvelles fonctions.
- Répéter : Les étapes ci-dessus se répètent automatiquement pour s’assurer que les cycles TDD couvrent toutes les fonctionnalités.
Différences entre le TDD et le développement traditionnel
Pour comprendre le TDD, il paraît pertinent de déterminer en quoi il diffère des approches traditionnelles de la programmation.
La principale différence est que les méthodes traditionnelles suivent un processus linéaire, tandis que le TDD adopte un processus cyclique.
Les programmeurs qui utilisent les méthodes de test traditionnelles commencent par écrire le code et ne se concentrent sur le test qu'à la fin du processus de développement. En revanche, celui qui suit le modèle TDD commence par créer le test puis développe le code qui répond à ce test. Cette approche partage de nombreux principes avec le mouvement shift left dans le domaine du test logiciel.
Alors que le programmeur qui utilise l'approche traditionnelle peut prêter attention à la justesse du code, il court le risque de ne pas détecter toutes les défaillances du code. Le programmeur qui adopte la méthode TDD travaille sur le code jusqu'à ce qu'il réussisse le test, en le refactorant si besoin. Cette opération est répétée jusqu'à ce que le code réponde à la fonctionnalité, un processus susceptible de produire moins de bogues.
TDD est-il plus lent ou plus rapide que le développement de test traditionnel ?
En ce qui concerne la vitesse du processus de programmation avec TDD, les statistiques sont contradictoires selon les sources.
Une étude de cas impliquant des équipes d'ingénieurs logiciels de Microsoft et IBM a conclu que « les équipes ont constaté une augmentation de 15 à 35 % du temps de développement initial » lorsqu'elles utilisaient la technique TDD. Cependant, l'étude précise que ces chiffres sont « estimés subjectivement par la direction » (Source).
Si l'on considère que les études de Microsoft et IBM indiquent des améliorations de qualité, on pourrait soutenir que, sur le long terme, TDD fait gagner du temps sur la correction des problèmes. Les équipes de Microsoft et IBM partageaient ce point de vue (Source).
Une étude axée sur les perceptions initiales de professionnels expérimentés utilisant TDD conclut qu’« après avoir surmonté les difficultés initiales pour savoir par où commencer et comment créer un test pour une fonctionnalité qui n’existe pas encore, les participants ont acquis une plus grande confiance pour mettre en œuvre de nouvelles fonctionnalités et apporter des changements grâce à une large couverture de tests » (Source). Cela semble indiquer que les choses s’améliorent avec le temps.
Dans un article publié sur la plateforme Medium.com, le programmeur et auteur de “Composing Software” et “Programming JavaScript Applications”, Erick Elliot s’attarde sur la façon dont TDD a changé sa vie. Elliot reconnaît que le processus peut être lent au début, mais il affirme : « Au bout d’environ deux ans, quelque chose de magique s’est produit : j’ai commencé à coder plus rapidement avec des tests unitaires que je ne l’avais jamais fait sans eux » (Source).
Il semble donc que l’adoption du TDD puisse ralentir les débuts. Cependant, si l’on adopte une perspective à long terme, le temps gagné grâce à une meilleure qualité du code pourrait compenser le temps perdu au départ. Par ailleurs, on peut s’attendre à ce qu’en se perfectionnant dans TDD, les programmeurs gagnent en rapidité.
Il existe également de nombreux autres facteurs à considérer lorsque l’on tente de mesurer le temps nécessaire pour obtenir un résultat de haute qualité. Pour approfondir la question, écoutez l’épisode de Niall Lynch sur le podcast The QA Lead consacré à la mesure du T2Q (Time To Quality).
Le TDD évite-t-il davantage les bogues ?
Dans la discussion ci-dessus, l’un des principaux avantages mis en avant pour TDD est qu’il aboutit à un code contenant moins de bogues. Mais les chiffres vont-ils dans ce sens ?
Les mêmes études menées auprès des équipes d’ingénierie de Microsoft et IBM citées plus tôt ont conclu que « la densité de défauts avant la mise en production des quatre produits a diminué de 40 % à 90 % par rapport à des projets similaires n’appliquant pas la pratique TDD. » Plus précisément, les équipes IBM ont signalé une baisse de 40 % de la densité de défauts, et celles de Microsoft une diminution de 60 à 90 % (Source).
Les statistiques sur le Test Driven Development appuient-elles la conclusion que le TDD produit une meilleure qualité ?
D’après les résultats d’une étude présentée lors du premier symposium international IEEE en 2007 en Finlande, Maria Siniaalto et Pekka Abrahamsson rapportent que TDD a démontré sa capacité à produire un code de meilleure qualité comparé à un logiciel développé sans TDD (Source).
Dans leur article, Siniaalto et Abrahamsson citent une étude menée en Chine qui a conclu que la TDD améliore le suivi des processus et l’estimation des tâches. La même étude conclut que « la TDD favorise également le respect de pratiques et de directives cohérentes. » Cela se traduit par une meilleure qualité avec moins de défauts. De plus, les équipes ayant utilisé la TDD ont pu corriger leurs défauts plus rapidement (Source).
Une étude réalisée auprès de développeurs ayant en moyenne une dizaine d’années d’expérience professionnelle, afin d’examiner leur perception lors de l’utilisation de la TDD, cite un développeur qui affirme : « La TDD m’a aidé à améliorer le code, le rendant plus lisible. » Un autre participant rapporte que « la TDD permet une meilleure maintenabilité » (Source).
La TDD favorise-t-elle un design plus simple ?
Boby George et Laurie Williams, tous deux travaillant au département d’informatique de l’université North Carolina State, ont mené une expérience dans laquelle 24 programmeurs ont été répartis en deux groupes : l’un utilisait la TDD et l’autre la démarche linéaire.
George et Williams rapportent que parmi les participants, « 92 % des développeurs pensaient que la TDD produit un code de meilleure qualité, 79 % estimaient que la TDD favorise un design plus simple et 71 % jugeaient l’approche nettement efficace » (Source).
Ces statistiques sur le développement piloté par les tests illustrent clairement que la TDD entraîne effectivement un code de meilleure qualité et un design plus simple.
Dans un article publié sur le portail d’apprentissage gratuit Guru99.com, Kanchan Kulkarni déclare : « La TDD rend le code plus simple et plus clair. Elle permet au développeur de maintenir moins de documentation » (Source).
Est-il facile d’adopter le design TDD ?
D’après l’expérience de George et Williams, 56 % des développeurs professionnels ont trouvé difficile d’adopter l’état d’esprit TDD, tandis que 23 % indiquent que l’absence d’une phase de conception préalable en est la raison. Au total, 40 % des réponses estiment que l’adoption de la TDD est difficile (Source).
Ces statistiques d’adoption du développement piloté par les tests montrent que la TDD est souvent perçue comme difficile à adopter.
La TDD est-elle surévaluée ?
Dans un article publié sur Medium.com, Tylor Borgeson, qui se décrit comme développeur Full Stack passionné par le machine learning, l’IA, l’infrastructure, le DevOps et l’Agile, utilise le titre « Le développement piloté par les tests est surévalué ». Cependant, le fait qu’il ait mis le titre entre guillemets montre qu’il ne fait pas cette affirmation lui-même.
Borgeson s’adresse ensuite à ceux qui affirment que la méthode est surévaluée et lente, en leur disant que la plupart de ceux qui partagent ce point de vue ne l’ont pas utilisée assez longtemps. Il conclut son article par : « Maintenant, entraînez-vous au développement piloté par les tests jusqu’à ce que cela ne fasse plus mal » (Source).
Et ensuite ?
Découvrez les approches QA auprès d’experts dans le podcast The QA Lead
Inscrivez-vous à la newsletter The QA Lead pour recevoir nos derniers guides pratiques et épisodes de podcast
Rejoignez la liste d’attente pour le forum communautaire en ligne The QA Lead où vous pourrez partager les meilleures pratiques avec d’autres professionnels du QA et des tests logiciels.
Au plaisir de vous y retrouver !
