Aller au contenu

Introduction au TDD

Objectifs pédagogiques

À la fin de cette page, vous serez capable de :

  • définir le Test Driven Development (TDD)
  • comprendre son principe fondamental
  • expliquer son intérêt pour la qualité logicielle
  • faire le lien avec les tests automatisés backend

Qu’est-ce que le TDD ?

Le TDD (Test Driven Development) est une méthode de développement qui consiste à écrire les tests avant le code de production.

Le développement suit un cycle court et répétitif appelé Red / Green / Refactor :

  1. 🔴 Red – écrire un test qui échoue
  2. 🟢 Green – écrire le code minimal pour faire passer le test
  3. 🔵 Refactor – améliorer le code sans casser les tests

Pourquoi pratiquer le TDD ?

Le TDD permet de :

  • clarifier le besoin avant de coder
  • produire du code naturellement testable
  • limiter fortement les régressions
  • améliorer la conception du logiciel
  • obtenir une documentation vivante via les tests

👉 Le test devient un outil de conception, pas seulement de vérification.

Exemple conceptuel (backend)

Exigence :

Calculer le prix total d’une commande avec TVA

Approche TDD :

  1. Écrire un test :
    « une commande de 100 CHF retourne 108 CHF avec TVA »
  2. Le test échoue (fonction inexistante)
  3. Implémenter le calcul minimal
  4. Le test passe
  5. Refactoriser si nécessaire

TDD et réalité du projet

Le TDD :

  • n’est pas toujours appliqué partout
  • demande de la rigueur et de la discipline
  • est particulièrement pertinent pour :
  • la logique métier
  • les règles de calcul
  • les services backend
  • les API

👉 Il est très adapté aux projets backend (ex. API, services).

Lien avec Clean Code

Le TDD pousse naturellement à :

  • des fonctions courtes et simples
  • des responsabilités bien séparées
  • un faible couplage
  • des dépendances injectées
  • un code plus lisible et maintenable

👉 TDD et Clean Code se renforcent mutuellement.

Exemple TDD – Fil rouge MyEvents

Dans l’application MyEvents, on a l’exigence suivante :

Un utilisateur ne peut pas acheter un billet si l’événement est complet.

Approche classique (sans TDD)

  • on code la fonctionnalité
  • on teste après coup
  • le cas “événement complet” peut être oublié

Approche TDD

1️⃣ Écrire le test (il échoue)

```text Given un événement avec une capacité maximale atteinte And un utilisateur authentifié When l’utilisateur tente d’acheter un billet Then l’achat est refusé And un message "Événement complet" est retourné

➡️ Le test échoue car la règle n’existe pas encore.

1️⃣ Écrire le test (il échoue)

À retenir

  • le TDD consiste à écrire les tests avant le code
  • le cycle Red / Green / Refactor structure le développement
  • le TDD améliore la qualité, la testabilité et la conception
  • ce n’est pas une obligation, mais un excellent levier de qualité

⬅ Debugging ➡ Tests des interfaces