Données de test : fixtures vs factories vs ensemencement

L'idée, en une ligne

Obtenez les données de votre test depuis la couche la plus basse qui reste fiable, et vérifiez votre résultat à la couche que vous testez réellement. Tout le reste est comment bien le faire.

Les quatre stratégies

• Fixtures (pytest) — installent et démontent un état autour d'un test : une session connectée, un fichier temporaire, une connexion BD. Leur scope (function, class, module, session) contrôle la fréquence du setup. Utilisez-les pour brancher les choses, pas pour tenir de gros blobs de données.
• Factories — construisent des objets à la demande avec des défauts réalistes et des surcharges faciles (factory_boy, ou un builder maison). Chaque test crée son propre utilisateur frais, donc les tests restent indépendants au lieu de partager un seul objet fragile.
• Ensemencement via API — créez les préconditions en appelant les propres endpoints de l'app, comme POST /users avant un test UI. Réaliste, et reste valide quand le schéma change, mais plus lent.
• Ensemencement en BD — insérez des lignes directement dans la base de données. Le plus rapide, et peut atteindre des états que l'UI ne peut pas, mais ça saute la validation et lie vos tests au schéma.

import pytest

# Factory: fresh, independent data per test
def make_user(**overrides):
    base = {"email": "t@example.com", "plan": "free", "verified": True}
    return {**base, **overrides}

# Fixture: API-seed a real user, then clean up after
@pytest.fixture
def seeded_user(api_client):
    payload = make_user(plan="pro")
    resp = api_client.post("/users", json=payload)   # seed via the app's API
    user = resp.json()
    yield user                                       # test runs here
    api_client.delete(f"/users/{user['id']}")        # teardown

def test_pro_dashboard(seeded_user, ui):
    ui.login(seeded_user)
    assert ui.dashboard.badge() == "PRO"

Lisez-le de haut en bas : la factory fabrique des données propres, la fixture utilise ces données pour ensemencer un vrai utilisateur via l'API, le test s'exécute au yield, et tout ce qui suit yield nettoie. Ce que vous créez, vous le supprimez.

Avancé — l'heuristique à dire à voix haute

Ensemencez le setup à la couche fiable la plus basse, puis vérifiez à la couche testée. Préférez l'ensemencement via API à l'ensemencement en BD sauf si la vitesse vous y force — l'ensemencement en BD est rapide mais contourne les propres règles de l'app, donc il peut créer des états qui ne pourraient jamais arriver pour un vrai utilisateur.

Basé sur la doc des fixtures pytest et la documentation factory_boy