Tests unitaires et d'intégration automatisés

Automatiser l’écriture de tests

Les tests sont la première chose qu’on repousse quand le temps manque, et la dette qui coûte le plus cher ensuite. Codex change l’arbitrage : générer une couverture complète sur un module devient une affaire de minutes plutôt que d’après-midi. Encore faut-il demander autre chose que « écris des tests », instruction qui produira une poignée de cas nominaux — verts, rassurants et sans valeur.

Générer des tests unitaires

Le levier principal consiste à nommer vous-même les cas limites. Vous connaissez votre domaine métier ; l’agent ne sait pas qu’une remise supérieure à 100 % arrive une fois par trimestre dans vos données.

"Génère les tests unitaires pour src/lib/pricing.ts. 
Utilise Vitest. Couvre tous les cas limites : prix négatif, 
remise > 100%, devise invalide, quantité zéro."

Codex analyse le code source, identifie les fonctions exportées, comprend leur logique, puis produit une suite qui couvre à la fois les chemins normaux et les cas que vous avez cités.

// src/lib/pricing.test.ts
import { describe, it, expect } from "vitest";
import { calculatePrice, applyDiscount, formatPrice } from "./pricing";

describe("calculatePrice", () => {
  it("calcule le prix total pour une quantité positive", () => {
    expect(calculatePrice(10, 3)).toBe(30);
  });

  it("retourne 0 pour une quantité de zéro", () => {
    expect(calculatePrice(10, 0)).toBe(0);
  });

  it("lance une erreur pour un prix négatif", () => {
    expect(() => calculatePrice(-5, 1)).toThrow("Prix invalide");
  });
});

describe("applyDiscount", () => {
  it("applique une remise standard", () => {
    expect(applyDiscount(100, 20)).toBe(80);
  });

  it("refuse une remise supérieure à 100%", () => {
    expect(() => applyDiscount(100, 150)).toThrow();
  });
});

Un détail vaut inspection : le message d’erreur attendu, « Prix invalide », a été repris de l’implémentation réelle et non inventé. C’est la signature d’un test écrit à partir du code plutôt qu’à partir d’un gabarit, et le premier point à vérifier en relisant une suite générée.

Générer des tests d’intégration

Pour une route API ou un service qui touche la base de données, il faut donner davantage de contexte, en particulier sur ce qu’il convient de simuler.

"Génère les tests d'intégration pour src/api/routes/orders.ts.
Utilise supertest pour les requêtes HTTP. Mocke le service 
Stripe avec vi.mock. Teste les scénarios : création de commande, 
commande avec produit inexistant, paiement échoué."

Codex fait bien la différence entre les deux niveaux de test : il configure les mocks appropriés, gère le setup et le teardown de la base de test, et simule les services externes. Nommer explicitement Stripe et supertest lui évite d’inventer une infrastructure parallèle à celle que votre équipe utilise déjà.

Couvrir un projet entier

Sur un projet qui manque structurellement de tests, une tâche globale est plus efficace qu’une série de demandes fichier par fichier.

"Analyse tous les fichiers .ts dans src/lib/ et src/services/. 
Pour chaque fichier qui n'a pas de fichier .test.ts correspondant, 
génère les tests unitaires. Vise une couverture de branches > 80%."

Codex traite alors les fichiers l’un après l’autre en adaptant les tests à chaque module ; comptez plusieurs minutes d’exécution pour une suite complète. Lancez cette tâche sur un dossier à la fois plutôt que sur src/ entier : au-delà, la pull request devient trop volumineuse pour être relue, et une suite de tests approuvée sans lecture ne protège personne.

Améliorer des tests existants

Codex ne se limite pas à créer ; il sait aussi diagnostiquer une suite qui rassure sans protéger.

"Analyse les tests dans src/__tests__/. Identifie :
- Les tests qui ne testent qu'un seul chemin (happy path)
- Les assertions trop vagues (toBeTruthy au lieu de toBe)
- Les tests qui partagent de l'état mutable
Corrige ces problèmes."

Ces trois symptômes expliquent la plupart des suites vertes qui laissent passer des bugs. Le troisième est le plus insidieux : des tests qui partagent un état mutable passent tant qu’ils s’exécutent dans l’ordre habituel, et se mettent à échouer aléatoirement le jour où vous activez la parallélisation.

Tests par type de composant

Le type de test à demander dépend directement de la nature du code, et l’instruction change avec lui.

Configurer AGENTS.md pour les tests

Plutôt que de répéter ces choix à chaque tâche, inscrivez-les une fois pour toutes dans une section dédiée d’AGENTS.md.

## Tests
- Framework : Vitest
- Commande : `npm run test`
- Couverture : `npm run test:coverage`
- Convention : fichiers .test.ts à côté du code source
- Mocks : utiliser vi.mock(), pas de mocks manuels
- Assertions : préférer toBe/toEqual à toBeTruthy/toBeFalsy
- Chaque test doit être indépendant (pas d'état partagé)

Avec ces sept lignes, Codex applique vos conventions à tous les tests qu’il génère, y compris lorsqu’un développeur pressé formule sa demande en trois mots. C’est la façon la plus économique de rendre la qualité de vos tests indépendante de celle des instructions.

Points clés à retenir

• Codex génère des tests adaptés à votre code, pas des tests génériques
• Précisez les cas limites que vous voulez couvrir dans vos instructions
• Codex distingue tests unitaires et tests d’intégration
• Utilisez AGENTS.md pour définir vos conventions de test
• Codex peut améliorer des tests existants, pas seulement en créer de nouveaux