Bénéfices du développement piloté par les tests : statistiques clés et études
Dans cet article, j'examine certaines statistiques et études sur le développement piloté par les tests afin de comprendre comment il est utilisé, ses avantages et les défis auxquels les équipes sont confrontées avec cette approche.
Traditionnellement, le processus de développement logiciel suit une approche linéaire. Cependant, au cours des dernières décennies, les systèmes agiles sont devenus de plus en plus populaires (jusqu'à 87 % des équipes adoptent une méthode agile ou proche de l’agile), le développement logiciel a commencé à intégrer différentes méthodologies qui prennent en compte les exigences et le caractère du projet.
La technique du développement piloté par les tests (TDD) fait partie des méthodes qui attirent l’attention dans le domaine du développement logiciel agile.
Envie d'en avoir plus avec The CTO Club ?
Créez un compte gratuit pour terminer cet article et rejoindre une communauté de CTO et de leaders en ingénierie partageant des cadres pratiques, des outils et des conseils pour concevoir, déployer et faire évoluer des technologies alimentées par l'IA.
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 affirment que « le développement piloté par les tests (TDD) fait partie des pratiques fondamentales du processus de développement Extreme Programming (XP) » (Source).
L’homme qui serait à l’origine du TDD aurait « déclaré en 2003 que le TDD favorise des conceptions simples et inspire confiance » (Source). Cependant, des questions subsistent concernant les affirmations sur la productivité et la qualité associées au TDD.
Nous avons pris le temps de rassembler les dernières statistiques sur le TDD afin de tester les affirmations faites à son sujet.
Cet article commence par définir le concept de TDD, et sa différence avec l’approche traditionnelle. Ensuite, nous examinons quelques statistiques qui valident ou réfutent les différents arguments avancés sur 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 rédigé avant que le développeur ne crée le code de production nécessaire pour satisfaire ce test. L’idée de base de cette technique est de permettre à l’auteur du code de prendre le temps de réfléchir à sa conception ou aux exigences avant d’écrire du code fonctionnel.
Processus TDD
- Rédiger le test : En TDD, toutes les nouvelles fonctionnalités commencent par la rédaction d’un test. Le programmeur doit comprendre le cahier des charges et les exigences de la fonctionnalité à développer. Pour ce faire, il devra examiner des histoires d’utilisateur et des cas d’utilisation afin de bien cerner l’objectif du nouveau code à développer.
- Le test échoue : Une fois le test rédigé par le programmeur, il l’exécute. Comme il n’existe encore aucun code pour le satisfaire, le test échouera. Cela confirme que la plateforme de tests automatisés fonctionne correctement et élimine la possibilité que le nouveau test réussisse toujours parce qu'il est défaillant.
- Écrire le code : Maintenant que le programmeur sait que la fonctionnalité fonctionne selon le design, il écrit le code qui permet de faire passer le test. Le code n'est peut-être pas parfait ou ne réussit pas le test de manière optimale, mais ce n’est pas grave. On n’attend pas du développeur qu’il écrive un code au-delà de la fonctionnalité que le test a été créé pour vérifier.
- Exécuter les tests : Sachant que la fonctionnalité fonctionne comme prévu, à chaque nouvelle livraison de code, le programmeur peut utiliser un outil de gestion des tests pour relancer ce test, ce qui lui permet de valider que sa dernière modification n’a pas cassé une fonctionnalité déjà existante.
- Refactoriser le code : En TDD, à mesure que la base de code grandit, elle doit être continuellement nettoyée. Étant donné que la priorité du programmeur dans les étapes précédentes était uniquement d’écrire le code, cette étape garantit l’efficacité. Elle permet d’améliorer la structure interne du code source du programme tout en préservant ses attributs externes. Cette étape permet de supprimer les duplications et d’ajouter de nouvelles fonctionnalités.
- Répéter : Les étapes ci-dessus sont automatiquement répétées pour garantir que les cycles TDD couvrent toutes les fonctionnalités.
Différences entre TDD et le développement traditionnel
Pour comprendre le TDD, il paraît judicieux 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 suit 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 écrire le test, puis développe le code qui satisfait à ce test. Cette approche partage de nombreux principes avec le mouvement Shift Left dans les tests logiciels.
Alors que le programmeur utilisant l’approche traditionnelle peut veiller à la justesse du code, il court le risque de ne pas détecter toutes les défaillances du code. Le programmeur qui utilise la méthode TDD travaille le code jusqu’à ce qu’il réussisse le test en le refactorant. Cela se fait jusqu’à ce que le code soit fonctionnel, un procédé qui a des chances de produire moins de bugs.
TDD est-il plus lent ou plus rapide que le développement traditionnel des tests ?
Concernant la question de savoir si le TDD accélère le processus de programmation, les statistiques divergent selon les sources.
Une étude de cas menée auprès d’équipes d’ingénieurs logiciels de Microsoft et IBM a conclu que « les équipes ont connu une augmentation de 15 à 35 % du temps de développement initial » lorsqu’elles utilisaient la technique TDD. Toutefois, l’étude précise que ces chiffres sont « estimés subjectivement par la direction » (Source).
Si l’on considère que les études menées par Microsoft et IBM indiquent qu’il y a eu une amélioration de la qualité, on peut soutenir qu’à long terme, le TDD permet d’économiser le temps qui aurait été consacré à la correction des problèmes. Les équipes de Microsoft et IBM étaient d’accord avec ce point de vue (Source).
Une étude axée sur les perceptions initiales de professionnels chevronnés utilisant le TDD conclut qu’« après avoir surmonté les difficultés initiales pour comprendre par où commencer et comment créer un test pour une fonctionnalité encore inexistante, les participants gagnent en confiance pour mettre en œuvre de nouvelles fonctionnalités et apporter des modifications grâce à une couverture de test étendue » (Source). Il semble donc que cela s’améliore avec le temps.
Écrivant pour la plateforme Medium.com, le programmeur et auteur de « Composing Software » et « Programming JavaScript Applications », Erick Elliot insiste sur la façon dont le TDD a changé sa vie. Elliot reconnaît que le processus peut être lent au début, mais il déclare : « vers la barre des deux ans, quelque chose de magique a commencé à se produire : j’ai commencé à coder plus rapidement avec des tests unitaires que je ne l’avais jamais fait sans eux » (Source).
Il semble donc qu’utiliser le TDD puisse ralentir les choses au départ. Cependant, dans une perspective à long terme, le temps gagné grâce à un code de meilleure qualité pourrait compenser le temps perdu au début. De plus, il est probable qu’au fur et à mesure que les programmeurs s’améliorent avec le TDD, ils gagnent en rapidité.
De nombreux autres facteurs sont également à considérer lorsqu’il s’agit d’estimer le temps nécessaire pour obtenir un résultat de haute qualité. Pour en savoir davantage, écoutez l’épisode de Niall Lynch dans The QA Lead sur la mesure du T2Q (Time To Quality).
Le TDD entraîne-t-il moins de bugs ?
Dans la discussion ci-dessus, l’un des principaux avantages mis en avant pour le TDD est qu’il réduit le nombre de bugs. Mais les statistiques le confirment-elles ?
Les mêmes études impliquant les équipes d’ingénierie de Microsoft et IBM mentionnées plus haut ont conclu que « la densité de défauts avant sortie des quatre produits a diminué de 40 % à 90 % par rapport à des projets similaires n’ayant pas utilisé la pratique TDD ». Plus précisément, les équipes d’IBM ont rapporté une baisse de 40 % de la densité des défauts et celles de Microsoft une baisse de 60 à 90 % (Source).
Les statistiques du développement piloté par les tests soutiennent-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 de l’IEEE en 2007 en Finlande, Maria Siniaalto et Pekka Abrahamsson rapportent que le TDD produit une meilleure qualité de code par rapport à des logiciels développés sans TDD (Source).
Dans leur article, Siniaalto et Abrahamsson citent une étude menée en Chine qui a conclu que le TDD a amélioré le suivi des processus et l’estimation des tâches. La même étude conclut que « le TDD favorise également le respect de pratiques et de lignes directrices cohérentes. » Cela se traduit par une meilleure qualité avec moins de défauts. De plus, les équipes qui utilisaient le TDD étaient davantage capables de corriger leurs erreurs plus rapidement (Source).
Une étude menée auprès de développeurs avec environ dix ans d’expérience professionnelle (en moyenne) pour enquêter sur leurs perceptions lors de l’utilisation du TDD cite un développeur qui affirme : « Le TDD m’a aidé à améliorer le code, le rendant plus lisible. » Un autre participant rapporte que « le TDD permet une plus grande maintenabilité » (Source).
Le TDD favorise-t-il une conception plus simple ?
Boby George et Laurie Williams, tous deux travaillant au Département d'informatique de la North Carolina State University, ont mené une expérience où 24 programmeurs ont été divisés en deux groupes : l’un utilisant le TDD et l’autre l’approche linéaire.
George et Williams rapportent que parmi les participants, « 92% des développeurs estimaient que le TDD produit un code de meilleure qualité, 79% pensaient que le TDD favorise une conception plus simple et 71% ont considéré que l’approche était clairement efficace » (Source).
Ces statistiques concernant le développement piloté par les tests sont de forts indicateurs que le TDD aboutit effectivement à un code de meilleure qualité et à une conception plus simple.
Dans un article publié par le portail d’apprentissage gratuit Guru99.com, Kanchan Kulkarni affirme : « Le TDD rend le code plus simple et plus clair. Il permet au développeur de maintenir moins de documentation » (Source).
Le TDD est-il facile à adopter ?
D’après l’expérience de George et Williams, 56% des développeurs professionnels estimaient qu’il était difficile d’adopter une mentalité TDD, tandis que 23% affirment que le manque de phase de conception en amont explique cette difficulté. Au total, 40% pensaient que l’adoption du TDD est difficile (Source).
Ces statistiques sur l’adoption du développement piloté par les tests indiquent que le TDD est perçu comme difficile à adopter.
Le TDD est-il surestimé ?
Dans un article publié sur Medium.com, Tylor Borgeson, qui se présente comme un développeur Full Stack intéressé par le Machine Learning, l’IA, l’infrastructure, le DevOps et l’Agilité, utilise le titre « Le développement piloté par les tests est surestimé ». Cependant, le fait qu’il ait mis ce titre entre guillemets montre que ce n’est pas une affirmation qu’il fait lui-même.
Borgeson s’adresse ensuite à ceux qui disent que la méthode est surestimée et lente, leur expliquant que la plupart des personnes ayant ce point de vue n’ont pas utilisé la méthode assez longtemps. Il termine son article en disant : « Maintenant, entraînez-vous au développement piloté par les tests jusqu'à ce que cela ne fasse plus mal » (Source).
Et maintenant ?
Découvrez les approches QA 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 du forum communautaire en ligne The QA Lead où vous pourrez partager les meilleures pratiques avec d’autres professionnels de l’assurance qualité et du test logiciel.
Au plaisir de vous y retrouver !
