Home Blogs Le Test-Driven Development est plus important que l’assurance qualité
Applications

Le Test-Driven Development est plus important que l’assurance qualité

About The Author

Outline

Beaucoup, sinon la plupart, dans le monde du logiciel en sont venus à considérer le développement piloté par les tests (TDD) étroitement comme un processus unique au développement de logiciels. De nombreuses discussions et débats ont porté sur l’utilisation d’outils ou de techniques spécifiques conçus pour appliquer chaque coin de code contre une liste prédéfinie d’exigences dans le but de démontrer qu’une base de code donnée fonctionne comme décrit. Comme cela arrive trop souvent, il devient difficile de séparer le signal du bruit et le principe de la pratique, et nous nous perdons dans les détails de la mise en œuvre et perdons de vue l’intention initiale. Par conséquent, prenons du recul et cherchons à reconsidérer la conversation entourant le développement axé sur les tests : plus précisément, qu’est-ce que c’est et comment peut-il aider votre entreprise ?

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 de mapper les exigences et les objectifs métier dans les exigences système correspondantes. Après cela, la question devient : comment écrivez-vous des logiciels pour répondre à ces exigences, et à mesure que votre projet et sa base de code se développent, comment vous assurez-vous que votre logiciel continue de répondre à ces exigences

Entrez dans Test-Driven Development.

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 passer, le refactoriser.

La notion est que vous commencez par un test qui décrit une fonctionnalité pour n’importe quelle fonctionnalité logicielle est 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 initial. La troisième étape, et sans doute la plus importante du cycle de vie, est de refactoriser ensuite le code.

Le logiciel d’écriture est difficile non seulement en raison de ses qualités intrinsèques, mais aussi en raison de sa nature dynamique. Les exigences de l’entreprise peuvent évoluer constamment et, par conséquent, les exigences logicielles doivent pouvoir s’adapter. Le code écrit aujourd’hui répondra aux besoins d’aujourd’hui, mais demain, ou dans un mois, quelque chose va changer, et par conséquent, le code d’aujourd’hui ne sera peut-être plus la meilleure façon 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 disposons maintenant d’un outil puissant qui nous permettra de déchirer, réécrire et autrement recâbler sans crainte notre code 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, la 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 prix d’efforts accrus de développement. Ce n’est pas une conclusion surprenante, étant donné que la rédaction de tests supplémentaires exigera des efforts supplémentaires – mais ce que les études de cette nature semblent laisser de côté est le principal avantage de la 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 mesures qui tentent de quantifier la productivité du développement se rapportent aux unités de travail au fil du temps. 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 « décalage à gauche » dans le contexte du cycle de vie du développement logiciel, c’est exactement à cela qu’il fait référence.

Un avantage supplémentaire à 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 à la prochaine itération.

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. L’important, quelle que soit la façon dont vous choisissez de l’implémenter, est qu’il apporte de la valeur à votre organisation. 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 du TDD, comme l’a prédit le prophète Clapton : « C’est dans la façon dont vous l’utilisez. »

Comme tout autre outil, l’efficacité et la valeur du TDD 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.

Refactoring culturel

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 le seul refactoring à avoir lieu. Si vous choisissez de mettre en œuvre une forme de développement piloté par test, il est important que la culture environnante s’adapte également pour soutenir ce style de philosophie de développement.

Dans le cas de TDD, l’échec le plus courant tend à être 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 la 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 se rétrécissent parce qu’après tout, quelqu’un doit écrire tous ces tests. Et il s’ensuit que pendant le temps de crunch, les tests et la documentation, et tout ce qui n’est pas considéré comme critique de mission sont jetés. Ce qui suit invariablement 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 du 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. Il peut même y avoir la différence entre reconnaître quand il est temps de diviser l’architecture globale en microservices discrets ou tout autre parmi une myriade d’améliorations potentielles. Sans cette étape, vous pouvez manquer des occasions d’introspection et d’amélioration progressive, et finalement votre base de code risque une transformation progressive (ou non) en une grosse boule de boue.

Pour tirer parti des avantages du développement piloté par les tests, il est important que la culture adopte une vision à long terme du processus dans son ensemble, et de son potentiel, et investisse le temps dans l’application du cycle complet de « rouge, vert, refactorisation », et pas seulement des éléments opportuns.

Nouveaux jouets brillants

Quand il s’agit de la conception d’un système dans son ensemble, souvent trop de temps est passé à planifier les spécificités d’un système sans écrire réellement 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 l’essai de ce-itis, où ils préconisent l’utilisation d’une technologie de saveur du mois, ignorant tous les signes avant-coureurs qui pourraient ne pas convenir à ce projet particulier en faveur de la possibilité d’essayer quelque chose de nouveau ou 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 revenons à 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 la TDD fonctionne pour l’équipe et pour l’entreprise. Si vous êtes entravé par vos outils, non seulement ils n’ajoutent pas de valeur, mais ils travaillent activement contre vous. Prenez soin d’évaluer minutieusement le cadre que vous avez l’intention d’utiliser, et prenez le temps de comprendre exactement comment vous l’utiliserez. Cette approche s’applique à toutes les décisions de conception, pas seulement à celles liées à la TDD !

Conclusion

En un mot, l’idée de quelque chose comme TDD est de fournir un cadre pour recueillir 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é devrait ê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 et ensuite oublier, et que, pour tirer efficacement parti de ces techniques, il faut veiller à adopter et à activer l’approche au niveau culturel avant de plonger dans les détails de la mise en œuvre tels que les cadres et les outils.