TDD — Test-Driven Development¶

Le cycle Red/Green/Refactor — écrire le test avant le code pour piloter la conception.

Le principe¶

TDD inverse l'ordre habituel : au lieu d'écrire le code puis les tests, vous ecrivez d'abord le test, puis le minimum de code pour le faire passer, puis vous refactorez.

Ce n'est pas une méthode de test — c'est une méthode de conception. Le test vous force a définir l'interface avant l'implémentation.

Le cycle Red/Green/Refactor¶

graph LR
    R["🔴 Red<br/>Ecrire un test<br/>qui echoue"] --> G["🟢 Green<br/>Ecrire le minimum<br/>pour que ca passe"]
    G --> RF["🔵 Refactor<br/>Nettoyer sans<br/>changer le comportement"]
    RF --> R

1. Red — écrire un test qui échoué¶

Ecrivez un test pour le prochain comportement que vous voulez ajouter. Le test doit échouer pour une raison claire (fonction inexistante, résultat incorrect — pas une erreur de syntaxe).

2. Green — faire passer le test¶

Ecrivez le minimum absolu de code pour que le test passe. Pas d'optimisation, pas de generalisation, pas de gestion d'erreurs superflue. Si le test attend 4, ecrivez return 4. Le prochain test forcera la generalisation.

3. Refactor — nettoyer¶

Le test passe. Maintenant, nettoyez le code et les tests sans changer le comportement. Eliminez la duplication, renommez, extrayez des fonctions. Les tests verts vous donnent un filet de sécurité.

Baby steps¶

Le TDD fonctionne par petits increments. Chaque cycle ajoute un seul comportement.

Exemple : validation d'email¶

Cycle 1 — une adresse valide :

# test_email.py
def test_email_valide():
    assert is_valid_email("user@example.com") is True

# email.py
def is_valid_email(email: str) -> bool:
    return True  # minimum pour passer le test

Cycle 2 — rejeter une adresse sans @ :

def test_email_sans_arobase():
    assert is_valid_email("userexample.com") is False

def is_valid_email(email: str) -> bool:
    return "@" in email  # generalisation forcee par le test

Cycle 3 — rejeter une adresse sans domaine :

def test_email_sans_domaine():
    assert is_valid_email("user@") is False

def is_valid_email(email: str) -> bool:
    if "@" not in email:
        return False
    local, domain = email.split("@", 1)
    return len(domain) > 0

Chaque test force une generalisation. Le code emerge des tests, pas d'une conception à priori.

TDD comme outil de conception¶

Design emergent¶

En TDD, vous ne concevez pas l'architecture en amont — vous la decouvrez à travers les tests. Le test vous oblige à :

• définir l'API avant l'implémentation
• penser aux cas d'utilisation avant les cas techniques
• garder les unites petites et decouples (sinon les tests sont penibles a écrire)

Les signaux du test¶

Quand pratiquer le TDD¶

Le TDD n'est pas toujours le bon outil. Voici un guide pragmatique :

Les erreurs courantes¶

Outils¶

Pour les exemples détaillés par langage, consultez les tutoriels :

• Tests Python
• Tests JavaScript