Les avantages du Test Driven Development

L’efficacité, pour relever le défi d’un planning toujours serré. La productivité, pour répondre aux enjeux « économiques » du projet. L’engagement, pour répondre aux attentes des développeurs et de leurs collègues. Afin que leur collaboration soit une belle trajectoire allant en droite ligne vers les objectifs de qualité et de conformité.

Ainsi quelle méthode choisir pour être « compatible » avec ces trois critères ? Nous proposons ici une réponse : le TDD ou le Test Driven Development.

Comment mettre en œuvre le TDD ?

En premier lieu il convient de lever toute ambiguïté. Le TDD est une méthode de développement. Il n’est pas une méthode de conduite de projet. Par ailleurs, sa méthode s’applique à toutes les méthodes de projets digitaux, qu’elles soient « agiles » ou qu’elles ne le soient pas.

Le TDD est donc une façon de mener les développements. C’est une méthode très proche de la pratique technique, au quotidien des développeurs.

En effet, d’après la définition du TDD, celui-ci implique que l’on écrive un test avant même de développer toute autre chose en matière de code (une classe, une fonction, une classe abstraite, une interface, …). Il existe même 3 lois à respecter pour pratiquer « légitimement » le TDD. Lorsque l’on regarde de près chacune de ces lois, on comprend qu’il s’agit ici de tests unitaires. Dont le rôle et l’intérêt ne vous est plus étranger depuis votre lecture de notre article sur « La vérité sur les tests unitaires ».😉

On peut trouver cette définition un peu réductrice. Et on aurait raison. La pratique des tests unitaires n’est pas le seul argument pour la pratique du TDD. De fait toutes les natures et types de tests peuvent et doivent intégrer votre pratique du Test Driven Development : tests d’acceptation, tests d’API, tests de performance, etc.

Ce qu’il faut surtout mettre en œuvre dans le TDD, ce sont des « conditions préétablies » qui vont valider le livrable produit. Ce livrable étant du code source, complexe ou moins, long ou moins, qui de fait, arrive « en second » dans l’ordre des tâches à effectuer d’un cycle de développement.

Que faut-il donc pour mettre en œuvre une méthode de TDD au sein de son équipe de développement ? En matière d’outils, sont nécessaires les frameworks d’exécution et les composants d’automatisation des tests (unitaires, acceptation, perf’). Chacun trouvera les composants techniques pour son environnement technologique propre. Ensuite il s’agit de s’y former (en priorité) puis de s’y frotter (dans un second temps). L’impact sur votre projet sera progressif, mais en tous cas bénéfique.

Impact sur les projets

En introduction, nous citions trois « qualités » attendues pour la méthode : efficacité, productivité, engagement. Le TDD dispose-t-il de ces trois qualités ?

Dans un projet digital, on peut considérer les critères de productivité et d’efficacité sous le même angle. Ils sont attendus indistinctement par les clients. Le projet doit être livré en temps et en heure et dans le budget prévu au départ. Certes ! N’oublions pas que le même client sera sensible à la qualité des livrables : conformité, performance, maintenabilité, etc.

Assurément, mettre en place des tests unitaires et d’acceptation, c’est s’assurer que la conformité sera au rendez-vous et qu’on fera évoluer le projet sans risque majeur de régression. Pour en être réellement convaincu, relisez encore une fois notre article sur les tests unitaires. 🙄 Oui, nous l'aimons bien cet article. 😊

Mais en termes d’efficacité et de productivité, ne risque-t-on pas à « allonger » les délais de livraison ? Et à ajouter une « charge » au budget pour la pratique des tests ? La réponse est : NON ! Les tests, surtout lorsqu’ils sont mis en œuvre dans le cadre du TDD, n’ont pas d’impact néfaste sur les budgets et les plannings d’un projet. Pour vous en convaincre également, visionnez notre webinaire sur le sujet 👇. 

C’est surtout sur le critère d’engagement qu’il faut préciser plusieurs faits intéressants. Commencer par « écrire » les tests c’est, pour les techniciens que sont les développeurs, une excellente façon de se confronter au métier et de le comprendre. Bien plus qu’en lisant une spécification et en essayant de la transcrire immédiatement en code (en classe, en fonction, en IHM même). Écrire un test qui va « valider » la spécification, c’est revenir efficacement à « l’analyse » que pratiquaient les « analystes programmeurs » avant qu’ils ne « soient plus que » des « développeurs ».

On comprend tout le bénéfice du TDD sur la qualité des développements qui subissent moins d’incompréhension et que sont livrés plus rapidement et plus conformes.

Le TDD a aussi un grand bénéfice lors de la phase de recette. Les tests automatisés sont d’excellents outils pour aider à des tâches de vérification qu’il faut répéter maintes fois et qui sont fastidieuses et chronophages. En phase de recette, les tests issus du TDD sont une aide efficace pour les non-techniciens qui procèdent aux vérifications.

En termes d’engagement, le TDD peut aboutir à un rapprochement entre « la technique » et « le métier ». Notamment grâce aux tests d’acceptation qui peuvent être co-construits, sur la base de spécifications fonctionnelles, de users stories, de prototypes ou maquette UX/UI.
Ainsi le TDD quitte son domaine de « simple » méthode de développement, pour accéder au rang d’une méthode de conduite de projet à part entière. Ici le Test Driven Development ouvre sur le Behavior Driven Development qui est un autre et prochain sujet.

Crédits photos :

• Jacob Ammentorp Lund
• gorodenkoff
• NanoStockk