Review des tests d'intégration API¶
Review en mode rapport d'abord, fix sur demande. Jamais d'édition spontanée, jamais de commit.
Étape 0 — Charger les rules¶
Lire AVANT toute review (source de vérité, ne pas reviewer de mémoire) :
projects/api/.cursor/rules/integration-test-conventions.mdc— le contrat : cibles, architecture 3 couches, fixtures build/seed, descriptors, seeding discriminant, naming, DO NOT.cursor/skills/upsert-integration-tests/SKILL.md— le how-to détaillé (grosses entités, auth, MSW, cron/worker, harness).cursor/rules/test-conventions.mdc— scope « tester le custom, pas la lib » + AI-slop checklist
Étape 1 — Collecter le scope¶
- Pending :
git status --short+git diff HEAD(staged + unstaged) - Branche :
git diff develop...HEAD - Filtre :
*.integration-test.ts+projects/api/tests/integration/**(fixtures/helpers touchés) - Union des deux si les deux existent ; si aucun fichier ne matche → le dire et s'arrêter
- Ne reviewer que les lignes ajoutées/modifiées. Les tests existants en anglais non touchés ne sont jamais flagués (migration FR progressive, hors scope)
Étape 2 — Checklist¶
Les numéros structurent le rapport ; le contenu des checks de conformité vit dans les fichiers chargés à l'Étape 0 — vérifier le diff contre eux, rien n'est restaté ici.
Checks review-specific¶
- Description ↔ comportement — le texte du
describe/itcorrespond à ce que le test fait réellement (arrange/act/assert) ; flaguer tout mismatch - Doublons — tests couvrant le même chemin de code + même assertion → proposer un merge concret
- AI slop — appliquer la AI-slop checklist de
test-conventions.mdcsur le diff
Checks de conformité (foyer entre parenthèses)¶
- Langue (contrat §Naming) — Quand/Alors FR, nesting
- Bonne cible (contrat §Cibles) — logique pure → unit test, le signaler
- Notre code, pas la lib (test-conventions §Scope)
- Frugalité (test-conventions §Scope)
- Fixtures (contrat §Writes ; détails : how-to upsert)
- Seeding discriminant (contrat §Seeder)
- Conformité structurelle (contrat §Routes/§Placement/DO NOT ; MSW : how-to upsert) — + commentaires strictement nécessaires (règle monorepo)
Étape 3 — Rapport¶
Findings groupés par check :
### <Check> — <n> finding(s)
- `fichier:ligne` [bloquant|recommandé|nit] — <constat> → <suggestion concrète>
- Doublons : montrer le test mergé proposé (code)
- Terminer par un récap compteur (X bloquants / Y recommandés / Z nits) — ou « rien à signaler »
- Aucune édition à ce stade
Étape 4 — Fix sur demande¶
N'éditer qu'après accord explicite de l'utilisateur (tout ou findings sélectionnés). Jamais de commit.