pytest : écrire des tests Python propres et efficaces

Tu viens encore de lancer ton script à la main, de lire la sortie console ligne par ligne et de te convaincre que « oui, ça a l’air bon » ? Chaque exécution manuelle te coûte une à cinq minutes. Multiplie par dix vérifications par jour, par cinq jours par semaine : c’est une demi-journée de travail envolée, chaque semaine, pour une tâche qu’un ordinateur ferait mieux que toi en quelques millisecondes.

C’est exactement le problème que résout pytest, le framework de tests le plus utilisé de l’écosystème Python. Dans ce tutoriel, tu vas apprendre à écrire des tests automatisés, lisibles et maintenables : assertions expressives, fixtures pour préparer tes données, parametrize pour multiplier les cas sans dupliquer le code, markers pour organiser tes campagnes de tests. À la fin, ta suite de tests tournera en une seule commande.

Pourquoi arrêter les tests manuels

Le test manuel souffre de quatre défauts qui s’accumulent avec le temps :

• C’est lent. Un test automatisé s’exécute en secondes ; sa version manuelle prend des minutes, et tu dois être devant l’écran.
• C’est peu fiable. Ton attention diminue au fil de la journée. Tu finis par survoler les résultats, surtout quand rien n’a changé depuis hier.
• C’est non reproductible. Impossible de garantir que ton collègue teste exactement les mêmes scénarios que toi, dans le même ordre.
• C’est un frein aux modifications. Sans filet de sécurité, chaque changement de code devient stressant : tu ne sais jamais si tu viens de casser quelque chose ailleurs.

Une suite de tests pytest inverse cette logique : elle rejoue l’intégralité de tes scénarios en une commande, détecte immédiatement les régressions, et sert de documentation vivante du comportement attendu de ton code. C’est aussi un excellent réflexe professionnel : la majorité des équipes de développement exigent des tests avant toute mise en production.

Installation de pytest

Première étape : installer pytest dans l’environnement virtuel de ton projet. Si tu gères tes dépendances avec Poetry, jette un œil à mon guide complet sur Poetry.

# Depuis la racine de ton projet, avec le venv activé
pip install pytest

# Vérifie l'installation
pytest --version

Ajoute ensuite pytest à tes dépendances de développement pour que tes collègues (et ton futur toi) disposent du même outillage :

pip install --group dev pytest        # pip 25.1+
# ou classique :
pip freeze | grep pytest >> requirements-dev.txt

C’est tout : aucune configuration n’est obligatoire pour démarrer. pytest découvre et lance automatiquement tous les fichiers commençant par test_ ou finissant par _test.py.

Ton premier test avec pytest

Imaginons un petit module calcul.py avec une fonction à tester :

# calcul.py
def additionner(a, b):
    """Retourne la somme de a et b."""
    return a + b

Crée un fichier test_calcul.py à côté (ou mieux, dans un dossier tests/, on y reviendra). La convention est simple : une fonction de test commence par test_ et contient au moins une assertion.

# test_calcul.py
from calcul import additionner

def test_additionner_deux_nombres():
    resultat = additionner(2, 3)
    assert resultat == 5

Lance la suite :

$ python -m pytest -v
================= test session starts ==================
collected 1 item

test_calcul.py::test_additionner_deux_nombres PASSED [100%]

================== 1 passed in 0.01s ===================

Note deux choses. D’abord, pas besoin de classe ni d’héritage : une fonction suffit, contrairement au module standard unittest. Ensuite, utilise toujours python -m pytest plutôt que pytest seul : cela ajoute le dossier courant au chemin Python et évite les erreurs d’import selon la structure de ton projet.

L’assertion : le cœur de pytest

Dans pytest, on n’utilise qu’une seule instruction : le bon vieux assert natif de Python. Pas besoin d’apprendre une vingtaine de méthodes comme assertEqual ou assertTrue. Là où pytest devient redoutable, c’est dans son rapport d’échec : quand une assertion échoue, il t’affiche la valeur réelle de chaque variable impliquée.

def test_additionner_negatifs():
    resultat = additionner(-2, -3)
    assert resultat == -4   # volontairement faux

E       assert -5 == -4
E        +  where -5 = additionner(-2, -3)

Tu vois immédiatement quoi corriger, sans relancer le programme en mode debug. Quelques formes d’assertions utiles au quotidien :

import pytest

def verifier_email(email):
    if "@" not in email:
        raise ValueError("email invalide")
    return email.strip().lower()

def test_normalisation():
    assert verifier_email("  Alice@Exemple.COM ") == "alice@exemple.com"

def test_email_sans_arobase():
    with pytest.raises(ValueError):
        verifier_email("pas-un-email")

def test_collection():
    paniers = ["A", "B", "C"]
    assert "B" in paniers
    assert len(paniers) == 3

La forme with pytest.raises(...) remplace le pénible try/except manuel : elle échoue si l’exception n’est pas levée, et tu peux même vérifier son message avec match :

def test_message_erreur():
    with pytest.raises(ValueError, match="email invalide"):
        verifier_email("oops")

Les fixtures : préparer proprement tes données de test

Un bon test suit souvent la structure Arrange – Act – Assert : préparer les données, déclencher l’action, vérifier le résultat. Quand la phase « Arrange » devient longue (créer un objet complexe, remplir une base temporaire, écrire un fichier), les fixtures entrent en jeu. Une fixture est une fonction annotée @pytest.fixture que tes tests déclarent simplement en paramètre : pytest la construit et l’injecte automatiquement.

# test_panier.py
import pytest
from panier import Panier

@pytest.fixture
def panier_rempli():
    """Un panier prêt à l'emploi avec trois articles."""
    p = Panier()
    p.ajouter("clé USB", prix=9.90, quantite=2)
    p.ajouter("câble HDMI", prix=12.50, quantite=1)
    return p

def test_total_panier(panier_rempli):
    assert panier_rempli.total() == pytest.approx(32.30)

def test_nombre_articles(panier_rempli):
    assert panier_rempli.nombre_articles() == 3

def test_panier_vide():
    assert Panier().total() == 0

Chaque test qui demande panier_rempli reçoit une instance neuve : aucun test ne pollue les données d’un autre, donc l’ordre d’exécution n’a aucune importance. Deux points de vigilance :

• Nombres flottants : compare toujours avec pytest.approx(), sinon 0.1 + 0.2 == 0.3 échouera à cause de l’arrondi binaire.
• Ressources à libérer : ajoute du code après le yield pour nettoyer (fichier temporaire, connexion…). pytest garantit l’exécution même si le test échoue.

@pytest.fixture
def fichier_temporaire(tmp_path):
    chemin = tmp_path / "donnees.csv"
    chemin.write_text("produit;prix\ncle_usb;9.90\n")
    yield chemin          # le test s'exécute ici
    # nettoyage automatique : tmp_path est déjà géré par pytest

Au passage, tmp_path est une fixture intégrée qui fournit un dossier temporaire unique par test — inutile de coder ta propre gestion de fichiers temporaires. Autre force : les fixtures composables. Une fixture peut dépendre d’autres fixtures, et une fixture déclarée dans un fichier conftest.py devient disponible pour tous les tests du dossier, sans import :

# tests/conftest.py — partagé par toute la suite
import pytest
from panier import Panier

@pytest.fixture
def catalogue():
    return {"clé USB": 9.90, "câble HDMI": 12.50}

@pytest.fixture
def panier_rempli(catalogue):
    p = Panier(catalogue)
    p.ajouter("clé USB", quantite=2)
    p.ajouter("câble HDMI", quantite=1)
    return p

Règle pratique : une fixture utilisée par un seul fichier reste dans ce fichier ; dès que deux fichiers de tests en ont besoin, elle migre dans conftest.py.

Parametrize : tester vingt cas sans dupliquer le code

Sans @pytest.mark.parametrize, tester une fonction sur dix entrées différentes se traduit par dix fonctions quasi identiques. Avec parametrize, tu écris le test une fois et tu listes les cas en paramètres :

# nombres.py
def est_premier(n):
    if n < 2:
        return False
    for diviseur in range(2, int(n ** 0.5) + 1):
        if n % diviseur == 0:
            return False
    return True

# test_nombres.py
import pytest
from nombres import est_premier

@pytest.mark.parametrize("nombre, attendu", [
    (2, True),
    (3, True),
    (4, False),
    (17, True),
    (25, False),
    (97, True),
])
def test_est_premier(nombre, attendu):
    assert est_premier(nombre) == attendu

pytest génère six tests indépendants, affichés séparément dans le rapport. En cas d’échec, tu vois exactement quel couple (nombre, attendu) pose problème. Tu peux aussi donner un identifiant lisible à chaque cas, précieux pour les jeux de données complexes :

@pytest.mark.parametrize("nombre, attendu", [
    pytest.param(2, True, id="plus-petit-premier"),
    pytest.param(4, False, id="carre-parfait"),
    pytest.param(-7, False, id="negatif"),
])
def test_est_premier_lisible(nombre, attendu):
    assert est_premier(nombre) == attendu

Bonne habitude : inclue toujours les cas limites — zéro, valeurs négatives, liste vide, chaîne vide, maximum autorisé. Ce sont eux qui cachent la plupart des bugs.

Les markers : organiser et filtrer tes tests

Tous les tests n’ont pas la même durée ni la même criticité. Les markers permettent d’étiqueter puis de filtrer. Les marqueurs intégrés les plus utiles :

import sys
import pytest

@pytest.mark.slow
def test_generation_rapport_complet():
    ...  # traitement de plusieurs minutes

@pytest.mark.skipif(sys.platform == "win32",
                    reason="dépend d'outils Linux")
def test_script_shell():
    ...

@pytest.mark.xfail(reason="bug #42, correction en cours")
def test_tri_cas_limite():
    ...

# Lancer uniquement les tests rapides
pytest -m "not slow"

# Lancer seulement la génération de rapport
pytest -m slow

Pour éviter l’avertissement PytestUnknownMarkWarning, déclare tes marqueurs personnalisés dans un fichier pytest.ini à la racine :

[pytest]
markers =
    slow: tests longs, à lancer avant les releases
addopts = -ra

Retiens aussi ces options en ligne de commande qui font gagner du temps : -k nom pour filtrer par mot-clé dans le nom du test, --lf pour ne relancer que les tests échoués précédemment, -x pour stopper au premier échec, et --tb=short pour des tracebacks compacts.

Organiser ses fichiers de tests

Sur un projet réel, la structure recommandée sépare clairement le code applicatif du code de test :

mon_projet/
├── src/
│   └── boutique/
│       ├── panier.py
│       └── facturation.py
├── tests/
│   ├── conftest.py            # fixtures partagées
│   ├── test_panier.py
│   └── test_facturation.py
├── pytest.ini                 # config : markers, options
└── requirements.txt

Trois règles simples suffisent :

• Un fichier de tests par module testé : panier.py → test_panier.py. Tout le monde retrouve son chemin.
• Des noms explicites : test_total_panier_avec_reduction plutôt que test_panier2. Le nom doit raconter le scénario.
• Un seul comportement par test : un test qui vérifie cinq choses échoue sans dire laquelle. Découpe-le.

Pour mesurer la couverture — le pourcentage de lignes exécutées par tes tests — installe le plugin officiel :

pip install pytest-cov
pytest --cov=boutique --cov-report=term-missing

Vise une couverture élevée sur la logique métier, mais ne chasse pas le 100 % aveuglément : un test qui valide un comportement réel vaut mieux que trois tests cosmétiques.

Huit bonnes pratiques pour des tests propres

1. Structure Arrange–Act–Assert. Trois blocs visibles dans chaque test : préparation, action, vérification. Un commentaire par bloc suffit quand le test grandit.
2. Nomme tes tests comme des phrases. test_retrait_superieur_au_sol_leve_une_exception se lit sans ouvrir le fichier.
3. Isole chaque test. Aucun test ne doit dépendre du résultat d’un autre ni de données partagées modifiables. Les fixtures garantissent un état neuf.
4. Utilise parametrize pour les variations, jamais le copier-coller de tests presque identiques.
5. Teste le comportement public, pas les détails internes. Si tu dois refactorer sans casser tes tests, ils sont bien écrits ; s’ils cassent à chaque retouche mineure, ils collent trop à l’implémentation.
6. Garde la suite rapide. Au-delà de quelques dizaines de secondes, tu ne la lanceras plus spontanément. Marque les tests lourds @pytest.mark.slow et simule les appels réseau avec monkeypatch ou le plugin responses.
7. Échoue volontairement une fois. Écris le test, vérifie qu’il échoue sur un bug réel, puis corrige le code. Un test qui n’a jamais été rouge peut être faux et vert pour de mauvaises raisons.
8. Lance pytest dans l’intégration continue. GitHub Actions ou GitLab CI rejouent la suite à chaque push : les régressions sont détectées avant la fusion. Pour aller plus loin sur la qualité globale, lis mon article sur la revue de code efficace.

Conclusion : ta première suite de tests, aujourd’hui

Récapitulons ton kit de départ : assert pour toutes les vérifications, pytest.raises pour les exceptions, @pytest.fixture pour la préparation des données, @pytest.mark.parametrize pour couvrir tous les cas, les markers pour trier rapide et lent, et un dossier tests/ propre avec son conftest.py. Rien de tout cela ne demande plus de dix minutes de mise en place.

Mon conseil : choisis un module existant de ton projet — idéalement une petite fonction pure — et écris trois tests dessus dès aujourd’hui : le cas nominal, un cas limite, un cas d’erreur. Exécute python -m pytest -v et savoure la sensation de voir six vérifications passer en une seconde. Ensuite, étends progressivement : les tests s’écrivent mieux par petites touches régulières qu’en marathon.

Si tu veux consolider tes bases Python avant d’industrialiser tes tests, notre formation Python : Les Fondamentaux t’accompagne pas à pas, avec des exercices corrigés et un accompagnement humain — car un bon outil comme pytest ne remplace pas un professeur : il multiplie ce que ton prof t’a appris à faire. Pour approfondir le sujet, consulte aussi le guide complet sur les tests unitaires et d’intégration avec pytest.

Et toi, combien de temps passes-tu encore à tester manuellement ? Lance la conversation en commentaire, je réponds à toutes les questions techniques.