4 conseils pour adopter le développement piloté par les tests (TDD) dans votre organisation

Comment réussir le déploiement de TDD dans votre organisation ?

Apprenez à maximiser les avantages de l'adoption de TDD et explorez le spectre de l'adoption de TDD, du puriste au TDD-ish.

Le développement piloté par les tests (TDD) consiste à écrire du code allégé et moyen avec un niveau élevé de couverture de test. Les développeurs écrivent le test pour une exigence avant d'écrire le code, et le code est considéré comme terminé dès que le test réussit. Ça a l'air génial, mais comment réussir à déployer TDD dans votre organisation? Nous allons explorer cela ici et je vous donnerai quelques conseils pour maximiser les avantages de l'adoption du TDD.

Pourquoi TDD?

Le principal avantage de TDD est qu'il aide les développeurs à créer du code maintenable et testable. Le TDD empêche également le fluage des fonctionnalités et le «placage d'or» du code en s'assurant que le code minimum nécessaire pour implémenter la fonctionnalité est créé. Valider que le bon code est en cours d'écriture rend également les équipes plus efficaces et évite de gaspiller de précieuses ressources de développement pour créer de mauvaises fonctionnalités.

Suivre TDD applique les tests unitaires en tant que pratique au sein de l'organisation. Mais ce n'est pas un test unitaire pour des raisons de test unitaire. C'est un moyen de vous assurer que vous créez du code testable, ce qui vous aide à réduire les coûts de maintenance et à maintenir une dette technique faible. En vous assurant que vous disposez d'une solide suite de régression, vous êtes instantanément averti lorsque quelque chose se brise à la suite de modifications de code.

L'une des principales raisons de l'intérêt croissant pour le TDD est que de nombreuses organisations sont en train de passer à des pratiques de développement agiles et se rendent compte que leurs pratiques de test existantes reposent trop sur les tests manuels de fin de cycle. Il y a certainement une place pour les pratiques de test de bout en bout, mais pour faire évoluer l'innovation de développement à la vitesse nécessaire pour rester compétitives, les organisations doivent déplacer les efforts de test vers la gauche. TDD est un processus qui garantit pratiquement que vous démarrez des projets de développement avec une base de tests saine pour garantir la qualité des logiciels tout au long du cycle de vie du développement.

Le spectre TDD

Pour des raisons pratiques, très peu de personnes qui développent des logiciels suivent la pure vision du TDD, pour plusieurs raisons. Le développement de logiciels modernes implique généralement l'intégration de bibliothèques, la connexion de code hérité et l'extension des fonctionnalités existantes. Beaucoup de gens n'ont pas le luxe d'écrire du code complètement nouveau, donc le TDD pur n'est pas pratique dans de nombreux cas. Au lieu de cela, de nombreuses personnes «faisant du TDD» se situent quelque part sur un spectre qui ressemble à ceci:

Bien que chaque organisation ait son propre ensemble de défis spécifiques avec TDD, les problèmes dont nous entendons le plus parler de nos clients s'inscrivent dans les trois types de base ci-dessus. Mais dans ce spectre, il existe de nombreux types de praticiens TDD:

Ninjas TDD

À une extrémité du spectre se trouvent des personnes qui pratiquent avec succès le TDD au niveau de la «ceinture noire». Ces personnes sont pleinement attachées aux principes TDD et n'écrivent pas quoi que ce soit d'artificiel avant d'écrire des tests - pas de squelette, pas de définitions, pas de nuthin '- et sont terminés dès que le test passe. En conséquence, le code est très efficace et hautement maintenable. Lorsque nous parlons aux ninjas TDD, ils reconnaissent souvent que leur succès dans la mise en œuvre de TDD est inégal entre les équipes au sein de leur organisation.

Pragmatiques TDD

Les suivants sur le spectre sont des personnes qui pourraient concevoir des classes, des signatures de méthodes, etc., puis écrire des tests par rapport à ces définitions. Au niveau de l'API, cela équivaut à écrire la définition OpenAPI / Swagger ou WSDL. Nous appelons cela l'approche pragmatique du TDD.

Cette approche est un peu plus facile à adopter car elle offre plus de structure et une plus grande clarté. Tout est compilé pour qu'une équipe puisse plus facilement travailler ensemble. Le compromis potentiel, cependant, est que les pragmatiques TDD ne parviennent pas toujours à atteindre la conception de code minimale et hautement efficace réalisée par les ninjas TDD.

TDD pour Legacy

Il y a beaucoup de gens qui aimeraient s'engager pleinement dans le TDD, mais n'ont pas le luxe de commencer avec du code greenfield. Ces personnes créent souvent des tests pour reproduire un défaut, ou pour tester le comportement attendu, afin de modifier ou d'étendre les fonctionnalités existantes basées sur le code hérité.

D'après notre expérience, un large segment de ceux qui s'identifient comme pratiquant le TDD se situent à ou près de ce point du spectre. La logique est que bien que le test et le code soient inextricablement liés, le test ne précède le code. Les tests précèdent cependant la change au code.

TDD-ish

À l'autre extrémité de notre spectre de ceux qui s'identifient comme TDD, il y a des personnes qui testent et codent en parallèle. Pour les praticiens TDD-ish, tant que le test et le code sont validés et gérés ensemble, le développement est considéré comme piloté par les tests.

4 conseils pour mettre en œuvre le développement piloté par les tests (TDD)

Alors, comment adoptez-vous avec succès le TDD? Suivez les quatre conseils ci-dessous pour réussir le TDD.

1. Appliquer TDD au code hérité

Un problème de mise en œuvre TDD courant fait son apparition lorsqu'une organisation a hérité d'un code non testable et qu'elle n'a pas la capacité de rembourser la dette technique. Le code doit-il être remanié? Si tel est le cas, combien de refactoring est-il nécessaire pour commencer à pratiquer le TDD de manière significative et réalisable?

S'il y a un mandat pour commencer à faire du TDD sur du code hérité, alors essayer d'implémenter le TDD idéal ne fonctionnera pas. Le code dont vous héritez n'a pas été construit avec la testabilité à l'esprit, l'auteur d'origine peut ne plus faire partie de l'équipe ou même de l'organisation, les bibliothèques dépendantes peuvent avoir changé, etc.

Ainsi, si le code hérité est déjà disponible et fonctionne, le risque associé à la dette technique est faible par rapport au risque de nouveaux travaux non testés. En appliquant TDD au nouveau code que vous écrivez, c'est-à-dire aux modifications du code existant, vous minimisez le risque et n'augmentez pas la dette technique.

Pour surmonter les défis liés au test du code existant, vous pouvez utiliser Jtest Parasoftla capacité de test unitaire de pour créer rapidement des tests significatifs. Parasoft Jtest analyse le code hérité et ses dépendances, réduisant ainsi le temps nécessaire pour créer des cas de test JUnit et implémenter le stub/mocking complexe requis pour le code préexistant.

2. Appliquer TDD aux microservices

Les architectures basées sur les microservices ont beaucoup plus de dépendances et de complexité que les piles d'applications traditionnelles, ce qui introduit beaucoup plus de volatilité dans l'environnement de test. La création de tests pour des applications basées sur des microservices et d'autres architectures complexes peut être difficile en raison de l'exigence de mocking et de stubbing avancés.

Une architecture basée sur des microservices, cependant, offre la possibilité de tirer parti des meilleures pratiques TDD de manière très efficace. Si vous envisagez de traiter le microservice comme l'unité, plutôt que comme l'unité de compilation, alors l'approche pragmatiste TDD devient très utile.

Lors de l'application de TDD au niveau de l'API, votre API est définie dans le contrat (OpenAPI/Swagger, WSDL). Une Solution de test API tels que Parasoft SOAtest, peut alors créer automatiquement des tests basés sur ces définitions. Vous êtes prêt à développer des fonctionnalités conformément aux définitions jusqu'à la réussite des tests SOAtest.

3. Activer l'équipe

TDD est généralement considéré comme une activité axée sur le développeur, généralement encapsulée en créant des tests dans un cadre de test unitaire, comme JUnit ou NUnit. Cependant, la plupart des organisations n'ont tout simplement pas assez de développeurs ou de temps pour couvrir tous leurs cas d'utilisation. C'est particulièrement un problème pour les organisations d'entreprise qui ont un mélange de rôles et de compétences contribuant à ses projets.

Tirer parti des pratiques TDD au niveau de l'API, comme décrit ci-dessus pour les microservices, vous aide à résoudre le problème des ressources techniques limitées en vous permettant de tirer parti de l'expertise des testeurs pour définir des tests par rapport au contrat. Avec cette approche, les analystes métier, les testeurs et d'autres ressources non développeurs peuvent contribuer aux efforts de test TDD.

Vous pouvez également utiliser une solution de virtualisation de services, telle que Parasoft Virtualiser, pour créer immédiatement une fonctionnalité simulée sur laquelle vous pouvez créer et exécuter des tests avant l'écriture de tout code.

4. Améliorez TDD avec BDD

Comme nous l'avons vu, il y a plusieurs avantages à implémenter TDD, mais en lui-même, TDD ne se traduit pas nécessairement par un code qui correspond aux exigences. Il garantit seulement que le code est couvert par des tests et que les tests réussissent. Voici où développement axé sur le comportement (BDD) entre en jeu. Plutôt que d’écrire du code jusqu’à ce que le test réussisse, les développeurs écrivent du code jusqu’à ce que le comportement soit implémenté.

Il convient de souligner qu'il y a eu des tentatives dans le passé pour définir le cadre fonctionnel avant d'écrire le code. (Est-ce que quelqu'un se souvient de la conception par contrat (DbC)?) En fait, BDD est la tentative la plus récente de mettre en œuvre une telle approche. Dans BDD (ou DbC, d'ailleurs), les pré- et post-conditions doivent être définies avant de créer un test ou un code.

BDD représente une opportunité de faire passer TDD au niveau supérieur. Si vous utilisez un langage BDD, tel que Gherkin, vous pouvez mettre à l'échelle les tests d'automatisation. Et Parasoft SOAtest (pour les tests API) et Parasoft Selenic (pour Tests d'interface utilisateur pilotés par sélénium) peut réduire la complexité technique de l'écriture du code de colle nécessaire et des définitions d'étape qui nécessitent normalement des ressources de développement.

Conclusion

La promesse du développement piloté par les tests est basée sur une philosophie de développement lean. Il vise à vous aider à produire un code efficace, testable et maintenable. Mais les conditions réelles ne facilitent pas toujours l'adoption du TDD. Parasoft vous aide à adopter les pratiques TDD d'une manière pratique pour votre organisation, vous permettant de maximiser vos ressources de développement/test.