Qu’est-ce que TDD ?
Dans le contexte d’une entreprise, le but du logiciel est d’ajouter de la valeur à cette entreprise. Pour cette raison, l’un des principaux défis de tout effort de développement est la mise en correspondance des exigences et des objectifs métier avec les exigences système correspondantes. Ensuite, la question devient : comment écrire un logiciel pour répondre à ces exigences, et à mesure que votre projet et sa base de code grandissent, comment vous assurer que votre logiciel continue de répondre à ces exigencesEntrez dans le développement piloté par test.
Test-Driven Development, ou TDD, est une méthodologie organisationnelle pour écrire des logiciels en écrivant des tests qui décrivent et exercent ce logiciel. À la base, TDD est une répétition de trois étapes : écrire un test qui échoue, le faire réussir, refactoriser.
La notion est que vous commencez par un test qui décrit une partie de fonctionnalité pour n’importe quelle fonctionnalité logicielle en cours de développement. Exécuter ce test pour la première fois devrait produire un échec, car le code testé n’a pas encore été écrit. Naturellement, l’étape suivante consiste ensuite à mettre en œuvre la fonctionnalité, dans le but de faire passer le test original. La troisième étape, et sans doute la plus importante du cycle de vie, consiste à refactoriser le code.
Écrire un logiciel est difficile non seulement en raison de ses qualités intrinsèques, mais aussi en raison de sa nature dynamique. Les exigences métier peuvent changer constamment et, par conséquent, les exigences logicielles doivent pouvoir s’adapter. Le code écrit aujourd’hui conviendra aux besoins d’aujourd’hui, mais demain, ou dans un mois à partir de demain, quelque chose va changer, et par conséquent, le code d’aujourd’hui pourrait ne plus être le meilleur moyen de résoudre un problème particulier. En introduisant un mécanisme pour comparer ce que le logiciel est faire à un enregistrement de ce que le logiciel devrait nous avons maintenant un outil puissant qui nous permettra de déchirer, de réécrire et autrement de recâbler notre code sans crainte pour répondre au mieux aux exigences d’aujourd’hui, car nous pouvons être sûrs que tant que tous nos tests réussissent, la sortie du système devrait être la même.
Pourquoi devrions-nous utiliser TDD?
Une étude menée en 2014 par l’Université d’Helsinki a révélé que, dans de nombreux cas, le TDD a produit des effets positifs en termes de défauts, de qualité, de complexité et de maintenabilité, mais que ces améliorations peuvent se faire au détriment d’efforts de développement accrus. Ce n’est pas une conclusion surprenante, étant donné que la rédaction de tests supplémentaires nécessitera des efforts supplémentaires – mais ce que les études de cette nature semblent laisser de côté est le principal avantage de TDD, qui est la rétroaction.
Fermer la boucle de rétroaction signifie raccourcir le temps nécessaire pour apporter un changement et apprendre quelque chose. Plus vous pouvez le faire rapidement, plus vous pouvez être agile. La plupart des indicateurs qui tentent de quantifier la productivité du développement se rapportent aux unités de travail au fil du temps, et en réduisant le temps nécessaire pour recevoir des commentaires exploitables, TDD permet une utilisation plus efficace de cette ressource précieuse. On dit que le temps, c’est de l’argent, donc l’avantage économique ici est évident. Si vous avez déjà entendu quelqu’un mentionner un « changement à gauche » dans le contexte du cycle de vie du développement logiciel, c’est exactement ce à quoi il fait référence.
Un avantage supplémentaire d’avoir une suite de tests pour votre application est que vous pouvez l’automatiser. Non seulement les développeurs peuvent exécuter ces tests dans le cadre du cycle de vie du développement, mais ils peuvent également être exécutés par d’autres systèmes dans le cadre de tests de fumée ou d’un pipeline ci/CD . En automatisant les étapes de livraison du code sur le marché, il permet une livraison plus rapide du produit dans son ensemble, ce qui accélère à son tour les commentaires que vous pouvez recevoir des utilisateurs, qui peuvent ensuite être interprétés et appliqués à l’itération suivante.
Les effets synergiques de ces deux points sont évidents : avec une base de code qui permet aux développeurs d’adapter continuellement la base de code aux besoins de l’entreprise, et la capacité pour l’entreprise de solliciter rapidement les commentaires de ses clients, le résultat est un système qui permet aux équipes de fournir plus de valeur avec moins de travail.
Tirer le meilleur parti de TDD
Le développement piloté par les tests n’est qu’une des nombreuses approches différentes pour tester les logiciels. La partie importante, quelle que soit la façon dont vous choisissez de la mettre en œuvre, est qu’elle apporte de la valeur à votre entreprise. Comme toute autre discipline, vous devriez vous sentir libre de l’utiliser, de l’adapter comme bon vous semble, ou de ne pas l’utiliser du tout, entièrement en fonction des besoins de votre organisation. Cela étant dit, si vous choisissez de marcher sur le chemin TDD, comme le prophète Clapton l’a prédit : « C’est dans la façon dont vous l’utilisez. »
Comme tout autre outil, l’efficacité et la valeur de l’ATD dépendent de sa mise en œuvre. Trop souvent, dans le développement de logiciels, divers outils ou techniques sont transformés en boucs émissaires pour expliquer les échecs ou les lacunes d’un projet, mais c’est un pauvre artisan qui blâme ses outils. Concentrons-nous donc sur la façon de tirer le meilleur parti de TDD.
Refactorisation culturelle
La dernière et la plus importante étape de TDD est de refactoriser le code – mais pour que TDD fonctionne, ce n’est probablement pas la seule refactorisation qui doit se produire. Si vous choisissez de mettre en œuvre une forme de développement piloté par les tests, il est important que la culture environnante s’adapte également pour soutenir ce style de philosophie de développement.
Dans le cas du TDD, l’échec le plus courant est que le cycle continu des tests d’écriture, les faisant passer, puis le refactoring n’est jamais réellement terminé, mais est plutôt court-circuité en sautant l’étape de refactoring. Le plus souvent, le problème n’est pas TDD, ou toute autre technique spécifique, mais plutôt la culture même dans laquelle le logiciel est développé.
Pas à la différence de la documentation, le refactoring semble être l’une des premières choses jetées par-dessus bord lorsque les délais ou les budgets sont restreints parce qu’après tout, quelqu’un doit écrire tous ces tests. Et il s’ensuit que pendant les périodes difficiles, les tests et la documentation, et tout ce qui n’est pas considéré comme critique pour la mission, sont abandonnés. Ce qui s’ensuit invariablement, c’est une baisse constante de la qualité globale de la base de code et, à sa place, une accumulation de dette technique.
Le refactoring est l’étape du processus qui s’efforce de transformer le code qui fonctionne simplement en une base de code plus propre et plus maintenable. C’est la partie qui permet aux développeurs de prendre du recul et de reconnaître les modèles au sein du système global et de prendre des décisions mieux informées sur la façon dont ils pourraient être adaptés pour être plus polyvalents ou pour reconnaître les anti-modèles émergents et prendre des mesures pour les atténuer. Cela peut même faire la différence entre reconnaître le moment où il est temps de diviser l’architecture globale en microservices discrets ou toute autre d’une myriade d’améliorations potentielles. Sans cette étape, vous pouvez manquer des opportunités d’introspection et d’amélioration incrémentale, et finalement votre base de code risque une transformation progressive (ou non) en une grosse boule de boue.
Pour profiter des avantages du développement piloté par les tests, il est important que la culture ait une vision à long terme du processus dans son ensemble et de son potentiel, et investisse le temps à appliquer le cycle complet « rouge, vert, refactoriser », et pas seulement les bits qui sont opportuns.
Jouets neufs brillants
Lorsqu’il s’agit de la conception d’un système dans son ensemble, trop de temps est souvent consacré à la planification des spécificités d’un système sans réellement écrire de code. Un projet « green field » peut être passionnant, avec tout le potentiel d’anticipation associé à une feuille de papier propre. Les ingénieurs et les architectes sont victimes de Try-this-itis, où ils préconisent l’utilisation d’une technologie de saveur du mois, ignorant tous les signes avant-coureurs qu’elle pourrait ne pas convenir à ce projet particulier en faveur de l’opportunité d’essayer quelque chose de nouveau ou de cool. Avance rapide de quelques mois et le framework-du-jour ne répond plus aux besoins de l’équipe, la qualité du code en souffre, et nous sommes de retour à la partie où la technologie devient le bouc émissaire du mauvais résultat du projet.
En fin de compte, ce qui est important, c’est que la technologie, la méthodologie ou le cadre utilisé pour faciliter le TDD fonctionne pour l’équipe et pour l’entreprise. Si vous êtes bloqué par vos outils, non seulement ils n’ajoutent pas de valeur, mais ils travaillent activement contre vous. Prenez soin d’évaluer minutieusement le framework que vous avez l’intention d’utiliser et prenez le temps de comprendre exactement comment vous allez l’utiliser. Cette approche est valable pour toutes les décisions de conception, pas seulement celles liées à TDD!
Conclusion
En bref, l’idée de quelque chose comme TDD est de fournir un cadre pour collecter les commentaires d’une manière plus rapide et pas simplement une technique pour empêcher les bogues d’apparaître dans votre base de code. Quelle que soit l’approche que vous choisissez, la clé doit être qu’elle permette à votre entreprise et à ses logiciels de s’adapter plus rapidement aux tendances changeantes et aux besoins de l’entreprise. En cours de route, gardez à l’esprit que TDD et ses homologues ne sont pas simplement quelque chose que vous pouvez demander à votre équipe de développement de mettre en œuvre puis d’oublier, et que pour tirer parti efficacement de ces techniques, il faut prendre soin d’adopter et de permettre l’approche à un niveau culturel avant de plonger dans les détails de la mise en œuvre comme les cadres et les outils.
