Test-Driven Development (TDD) en pratique : écrire des tests avant le code pour une qualité garantie
Obtenez un résumé intelligent et des insights personnalisés
Le TDD Test-Driven Development (développement piloté par les tests) est une méthode où le développeur écrit un test avant le code. Le cycle tient en trois temps : un test échoue. Le code le fait passer. Puis, le développeur nettoie. Selon l’étude de Nagappan et ses collègues (Microsoft et IBM, 2008), le TDD réduit la densité de défauts de 40 à 90 %.
Un code livré sans tests casse au moindre changement. Les régressions s’accumulent, et chaque évolution coûte plus cher que la précédente. Alors, expliquons le TDD pas à pas, avec des exemples en JavaScript et TypeScript. Chez AquilApp, nous appliquons cette pratique sur nos projets web et mobile.
Comment fonctionne le cycle red-green-refactor ?
Le red-green-refactor est le cycle en trois étapes du TDD Test-Driven Development. Kent Beck l’a formalisé dans Test-Driven Development: By Example (2002).
- Red (rouge) : vous écrivez un test pour une fonction qui n’existe pas encore. Il échoue, et c’est normal.
- Green (vert) : vous écrivez le code minimal qui fait passer le test. Vous ne cherchez pas l’élégance à ce stade.
- Refactor (refactorisation) : vous améliorez le code sans changer son comportement. Les tests vous protègent pendant cette étape.
Le cycle dure quelques minutes. Vous le répétez pour chaque petit comportement, jusqu’à couvrir la fonctionnalité entière.
Pourquoi écrire les tests avant le code change la donne ?
Écrire le test d’abord force à définir le résultat attendu avant de coder. Le TDD Test-Driven Development devient une spécification exécutable, vérifiable à chaque modification.
L’étude de Nagappan et al. (Empirical Software Engineering, 2008) a suivi quatre équipes chez Microsoft et IBM. Les projets en TDD affichaient 40 à 90 % de défauts en moins que des projets comparables. Le temps de développement initial augmentait de 15 à 35 %.
Par ailleurs, le TDD améliore aussi la conception. Un code difficile à tester révèle souvent un couplage trop fort. Vous corrigez le problème avant qu’il s’installe.
Comment pratiquer le TDD Test-Driven Development avec JavaScript et TypeScript ?
Jest est un framework de test JavaScript maintenu par la communauté OpenJS. Vitest est un framework de test compatible avec l’API de Jest, conçu pour les projets construits avec Vite. Les deux tournent aussi avec TypeScript.
Voici un exemple. Le test s’écrit en premier et échoue :
ts
import { calculerTTC } from ‘./prix’;
test(‘applique 20 % de TVA’, () => {
expect(calculerTTC(100)).toBe(120);
});
Le code minimal fait ensuite passer le test :
ts
export const calculerTTC = (ht: number) => ht * 1.2;
Le typage TypeScript complète les tests en bloquant une partie des erreurs à la compilation. Notre comparatif TypeScript vs JavaScript détaille ce point. Jest est aussi le framework de test par défaut de React Native, ce qui sert directement les projets mobiles.
Comment appliquer le TDD au back-end ?
Sur le back-end, le TDD consiste à écrire le test d’une route d’API avant la route elle-même. Vous décrivez la requête envoyée, le code HTTP attendu et le corps de la réponse.
La bibliothèque Supertest permet de simuler ces requêtes sans lancer de serveur. Vous testez ensuite chaque service métier de façon isolée, avec des dépendances simulées (mocks). Un service qui calcule un tarif se teste ainsi sans base de données.
Comment appliquer le TDD Test-Driven Development au front-end ?
Sur le front-end, on teste ce que voit l’utilisateur, pas le fonctionnement interne du composant. React Testing Library est une bibliothèque de test qui interroge l’interface comme le fait un utilisateur. La documentation de Testing Library recommande cette approche.
Vous écrivez d’abord un test qui clique sur un bouton et vérifie le texte affiché. Le composant vient ensuite. Ce test reste valide si vous réécrivez le code interne du composant.
Quelle approche choisir entre le TDD, BDD ou les tests classiques ?
Le BDD (Behavior-Driven Development, développement piloté par le comportement) est une extension du TDD. Dan North l’a introduit en 2006 pour rapprocher développeurs et métiers.
| Critère | TDD | BDD | Tests classiques (après le code) |
|---|---|---|---|
| Moment d’écriture | Avant le code | Avant le code | Après le code |
| Langage des tests | Technique | Naturel (Given/When/Then) | Technique |
| Public principal | Développeurs | Développeurs et métiers | Développeurs et testeurs |
| Usage type | Logique unitaire | Parcours fonctionnels | Vérification finale |
Sources : Beck, 2002 ; North, « Introducing BDD », 2006 ; Fowler, « Test Pyramid », martinfowler.com.
Nous recommandons le TDD pour la logique métier et le BDD pour les parcours validés avec le client. Les tests écrits après le code restent utiles pour le code existant.
Quelles objections au TDD, et comment y répondre ?
Evidemment, le TDD Test-Driven Development ne fait pas toujours l’unanimité. Voici quelques points faibles que l’on a relevé des avis en ligne. Néanmoins, ils ne sont pas irreversible.
« Le TDD ralentit le projet. » Le surcoût initial est réel, de 15 à 35 % selon Nagappan et al. (2008). Il se rembourse par la baisse des corrections après livraison.
« Mon code existant n’a pas de tests. » Vous n’avez pas à tout couvrir. Appliquez le TDD à chaque nouvelle fonctionnalité et à chaque bug corrigé.
« Mes tests cassent à chaque refactorisation. » Vos tests dépendent alors de l’implémentation. Testez le comportement visible plutôt que les détails internes.
FAQ sur le TDD Test-Driven Development
Conclusion
Le TDD Test-Driven Development repose sur un cycle simple : rouge, vert, refactorisation. Il réduit les défauts et clarifie la conception, au prix d’un temps initial plus long.
Pour l’intégrer à votre organisation, consultez notre guide sur la méthode DevOps et le cycle de développement logiciel. Le recettage informatique complète les tests automatisés.
Notre équipe de Nantes applique le TDD sur ses projets web et mobile. Découvrez notre agence de développement logiciel sur mesure.
