Dans l'environnement de développement logiciel en constante évolution d'aujourd'hui, il est courant d'entendre les mots Test-Driven Development (TDD). Les discussions sur ses avantages et ses inconvénients sont très courantes dans la communauté des développeurs de logiciels.
Certains disent que le TDD est une « campagne de moralité irréaliste et inefficace visant à inciter à la haine de soi et à la honte » et d'autres qu'il s'agit « simplement d'un outil qui nous aide à concevoir plus rapidement grâce à la refactorisation » [2].
« Les mauvais programmeurs ont toutes les réponses. Les bons testeurs ont toutes les questions. »
— Gil Zilberfeld
Mais le développement piloté par les tests n'est pas une nouveauté.
La première référence largement connue remonte à 1957 dans « Digital Computer Programming : The First General Introduction in Book Form, Stressing Actual Work with Computers » de D.D. McCracken. Bien que le TDD n'ait pas été largement adopté au cours des quelques années qui ont suivi, IBM a dirigé un projet pour la NASA dans les années 1960, lorsque les développeurs « écrivaient les premiers tests unitaires par micro-incréments ».
Au cours d'une chaude soirée d'été de 1989, Kent Beck a développé le premier framework TDD connu - SUnit - et je l'ai essayé sur Smalltalk. Le TDD est alors né ou, plus exactement, redécouvert. Peu de temps après, les mouvements Agile et TDD ont commencé à encourager les programmeurs à écrire des tests unitaires automatisés, ajoutant ainsi les tests à la discipline de développement.
Au début, comme pour beaucoup de nouveautés, cela semblait simplement « ajouter du temps au travail quotidien ». La plupart d'entre nous ne comprenaient pas très bien les avantages de suivre de telles pratiques, étant sceptiques et critiques à l'égard du TDD, car cela était considéré comme un temps et des efforts inutiles.
Mais avant d'aller plus loin, prenons du recul et examinons : Qu'est-ce que le développement piloté par les tests ?
En bref, Le TDD est l'acte d'écrire un test automatique avant d'écrire une fonctionnalité.
À titre d'exemple, supposons que Bob ait besoin de développer une nouvelle fonctionnalité pour sa nouvelle idée géniale de réseau social. Bob commence par écrire un test automatique et, tant que la fonctionnalité n'est pas implémentée correctement, le test échouera (voyant rouge). Bob écrit donc la quantité minimale de code pour réussir le test (c'est-à-dire le feu vert).
Ensuite, une fois qu'il a le feu vert, Bob nettoie le code et s'assure que la fonctionnalité est toujours correctement implémentée en exécutant les tests (c'est-à-dire qu'il refactorise le code). Sans doublons, le code et les tests automatisés sont faciles à gérer pour les autres.
Cette procédure est également connue sous le nom de « mantra rouge/vert/refactorisation », où le rouge signifie l'échec des tests et le vert signifie la réussite des tests. Robert Cecil Martin, l'un des leaders du mouvement des méthodologies agiles (et que beaucoup connaissent sous le nom d'Oncle Bob), a mentionné dans « Clean Code » que l'écriture de tests avant d'écrire du code de production n'est que la partie visible de l'iceberg.
« La seule façon de respecter la date limite, la seule façon d'aller plus vite, est de garder le code aussi propre que possible à tout moment. »
— Oncle Bob, Code propre
Pour mettre en évidence les avantages réels du TDD, nous allons faire un exercice.
Imaginons que nous allons démarrer une nouvelle application logicielle sans développement piloté par les tests. Nous allons mettre en place une application permettant aux utilisateurs de gérer leur blog.
Commençons par implémenter notre première fonctionnalité : permettre aux utilisateurs de s'inscrire afin de créer leur blog. Une fois le code terminé, nous devons le tester manuellement pour voir si tout fonctionne correctement.
Lorsque nous serons satisfaits de la première fonctionnalité, nous pourrons commencer à coder la fonctionnalité numéro deux : autoriser les utilisateurs à ajouter des articles de blog. Et, une fois ce code terminé, nous testons la deuxième fonctionnalité manuellement pour voir si elle fonctionne correctement. Une fois que nous serons satisfaits, nous pourrons passer à la fonctionnalité suivante, non ?
Mais... comment savons-nous que le nouveau code n'a pas interrompu le processus d'enregistrement des utilisateurs (première fonctionnalité) ?
Nous pouvons tester la première fonctionnalité manuellement et voir si elle fonctionne toujours. Cela signifie-t-il que chaque fois que nous ajoutons une nouvelle fonctionnalité, nous devons exécuter manuellement N+1 tests ?
La réponse est oui.
Le résultat est que il est tellement coûteux de tester manuellement toutes les fonctionnalités chaque fois qu'une nouvelle version est publiée, que les projets sans TDD sont très sujets aux régressions. En termes de développement logiciel, une régression se produit lorsqu'une fonctionnalité qui fonctionnait dans une version précédente semble être interrompue dans une version ultérieure.
La conclusion est que les projets où le TDD est appliqué présentent généralement moins de bogues que les projets sans tests automatisés. Mais les tests automatisés ne sont pas gratuits.
À première vue, le développement d'une fonctionnalité avec des tests automatisés peut coûter de 20 à 50 % de plus que sans tests. Cependant, à mesure que la complexité du logiciel augmente, il devient de plus en plus difficile de tester manuellement chaque fonctionnalité.
Après la mise en œuvre de quelques fonctionnalités, investir du temps dans la rédaction de tests automatisés est déjà rentable.
Dans la communauté des développeurs de logiciels, il est désormais largement admis que les projets comportant des tests automatisés sont moins bogués que les projets sans tests automatisés.
Il est également largement admis que les frais liés à la rédaction d'un test sont rentables en empêchant les bogues d'atteindre l'environnement de production. Moins de bugs signifie un meilleur produit. Et cela se traduit généralement par des utilisateurs plus satisfaits. Sans parler de développeurs plus satisfaits, qui peuvent passer leur temps à créer un meilleur produit, au lieu de constamment corriger des bogues.
Mais quelle quantité de tests est suffisante ? Devons-nous écrire des tests automatisés pour chaque fonctionnalité ?
La réponse est : cela dépend.
Dans le TDD, il n'existe pas de plan de test officiel, ce qui en fait un processus informel. Par conséquent, le pourcentage de code qui doit être testé est un énorme débat.
« 'Comment tester ? ' est une question à laquelle il n'est pas possible de répondre en général. « Quand faire le test ? » a toutefois une réponse générale : le plus tôt et le plus souvent possible. »
— Bjarne Stroustrup, le langage de programmation C++
Nous avons observé que le fait de porter la couverture des tests à plus de 80 % n'apportait pas de meilleurs avantages. Nous avons rencontré si peu de bugs lorsque nous avons appliqué la règle des 80 % que l'écriture d'un plus grand nombre de tests n'a eu que des avantages très, très marginaux.
Pour le mettre dans le monde réel, prenons juste un exemple.
Récemment, dans le cadre d'un projet de plate-forme étendue, en raison de la pression sur les délais de quelques sprints, nous avons été contraints de réduire la couverture des tests automatisés à 60 % du code.
Au fur et à mesure que de nouvelles fonctionnalités étaient publiées avec une couverture plus faible, nous avons commencé à obtenir de plus en plus de régressions. Après avoir effectué deux sprints avec une couverture de code de 60 %, nous avons décidé d'utiliser un sprint complet uniquement pour corriger les bogues et remettre la couverture des tests sur la bonne voie.
S'il n'y avait pas eu de baisse de couverture, nous n'aurions été retardés que d'un demi-sprint, au lieu d'un sprint complet. Cela représente donc une semaine entière que nous aurions pu économiser simplement en augmentant la couverture de nos tests dès le départ.
Imaginez ce que l'on ressent lorsqu'on passe du temps à balayer ses affaires, au lieu de construire des choses plus grandes et meilleures.
Notre règle générale est de toujours appliquer des tests automatisés pour les fonctionnalités les plus complexes. Nous ne développons des tests automatisés pour des fonctionnalités simples que si la couverture sans celles-ci est inférieure à 80 %. Cela signifie que nous passons moins de temps à corriger les bogues et que moins de problèmes sont soulevés par les utilisateurs finaux.
Donc, pour résumer, à Imaginary Cloud nous adorons TDD et Une couverture de 80 % du code est notre chiffre magique.
Plus la fonctionnalité est complexe, plus elle figure en tête de notre liste de priorités de test.
Nous avons une équipe d'experts en développement de logiciels à Imaginary Cloud. Si vous pensez avoir besoin d'aide pour votre projet numérique, écrivez-nous ici!
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
