Cycle TDD & pytest — antisèche
Le cycle
- Rouge — écrire un test qui échoue, pour un comportement qui n’existe pas encore. Le voir échouer pour la bonne raison (pas une erreur de syntaxe).
- Vert — écrire le code le plus simple possible qui fait passer le test. Tricher est permis (valeur en dur) si ça fait passer le test — le prochain test forcera à généraliser.
- Refactor — nettoyer le code (et les tests) sans changer le comportement, tests toujours au vert.
Règle d’or : jamais plus d’un test qui échoue à la fois.
Style classiciste (rappel)
- Utiliser des objets réels par défaut.
- Un double de test (stub/fake) seulement si l’objet réel est lent, non déterministe, ou a des effets de bord externes (réseau, disque, horloge).
- Vérification par état : on inspecte l’état final de l’objet, pas les appels qu’il a faits (à l’inverse du style mockiste — voir Mocks Aren’t Stubs).
pytest — le strict minimum
# fichier: test_compte.py
def test_nouveau_compte_a_solde_zero():
compte = CompteBancaire()
assert compte.solde == 0| Élément | Règle |
|---|---|
| Fichiers | test_*.py ou *_test.py |
| Fonctions | def test_...(): |
| Assertions | assert nu — pytest réécrit l’assertion pour un message détaillé |
| Lancer | pytest, pytest -v (verbeux), pytest -x (stop au 1er échec) |
Exception attendue :
import pytest
def test_retrait_refuse_si_solde_insuffisant():
compte = CompteBancaire()
with pytest.raises(SoldeInsuffisant):
compte.retirer(10)Piège : un rouge pour la mauvaise raison
Un test qui échoue à cause d’une faute de frappe ou d’un import manquant n’est pas un vrai rouge TDD — corrige-le avant de continuer. De même, si plusieurs tests sont rouges en même temps, c’est qu’on est allé trop vite : reviens à un seul test rouge à la fois.
🗂 Voir la leçon : Le cycle rouge-vert-refactor.