Le test d’abord, seul
Décris le comportement attendu et demande uniquement le test. Interdis explicitement de toucher au code de production à cette étape.
1 · Le piège principal
Le test décoratif
C’est le défaut le plus fréquent du code de test généré : il vérifie la mécanique du test lui-même plutôt que le comportement du code.
✗ Le test qui teste le mock
Le mock renvoie ce qu’on lui a dit de renvoyer, et on vérifie qu’il l’a fait. Ce test passera toujours, même si tu supprimes toute la logique métier.
const db = mock({ getUser: () => ({ id: 1 }) })
const res = await getUser(1, db)
expect(res.id).toBe(1)✓ Le test qui teste une décision
On vérifie une règle métier réelle, avec un cas où le code doit choisir. Si la règle change ou disparaît, le test tombe.
// Règle : un compte suspendu ne peut pas commander
const account = { status: "suspended" }
await expect(placeOrder(account, cart))
.rejects.toThrow("account_suspended")
Le test de mutation, en version manuelle : casse volontairement une
ligne de logique (inverse une condition, supprime une validation) et relance la suite.
Si tout reste vert, tes tests sont décoratifs. C’est trente secondes de vérification
qui valent plus que n’importe quel pourcentage de couverture.
2 · Le tri
Quoi tester, et quoi laisser tranquille
Un agent à qui on demande « écris des tests » en produit pour tout, y compris pour ce qui n’en a pas besoin. Le volume de tests n’est pas un objectif : c’est un coût de maintenance.
Un test utile est un test qui échoue quand le comportement casse. S'il reste vert quoi qu'il arrive, il ne te protège pas — il te rassure, ce qui est pire.
Le critère unique pour juger une suite de tests| Priorité | Quoi | Pourquoi |
|---|---|---|
| Toujours | Règles métier, calculs, autorisations, transitions d’état | C’est là que les bugs coûtent de l’argent ou de la confiance |
| Toujours | Chaque bug corrigé (test de non-régression) | Un bug qui est arrivé une fois peut revenir. C’est le meilleur rapport valeur / effort |
| Souvent | Les bords : null, vide, zéro, négatif, très grand, caractères spéciaux | C’est la zone la plus faible du code généré |
| Souvent | Les parcours critiques de bout en bout (login, paiement, envoi) | Un seul test qui couvre la chaîne réelle vaut vingt tests unitaires isolés |
| Rarement | Getters, setters, wrappers triviaux, code sans décision | Aucune logique à protéger, mais du code à maintenir en plus |
| Jamais | Le comportement des librairies tierces | Ce n’est pas ton code, et leurs auteurs les testent déjà |
3 · La méthode
Le TDD, meilleur allié d’un agent
Écrire le test avant le code est la façon la plus fiable de travailler avec une IA, parce que la réussite devient mécaniquement observable. L’agent ne peut plus « croire » que ça marche.
Vérifier qu’il échoue
Étape non négociable, et celle qu’on saute le plus. Un test qui passe avant l’implémentation ne teste rien du tout.
Implémenter au minimum
Juste ce qu’il faut pour faire passer le test, sans anticiper des besoins imaginaires. C’est aussi le meilleur remède à la sur-abstraction.
Nettoyer sous protection
Le refactor devient sûr : si un test tombe, tu sais exactement ce que tu viens de casser.
Demande à ton agent
On travaille en TDD sur : [le comportement voulu].
Étape 1 — uniquement le test :
écris le test qui décrit ce comportement, y compris
les cas limites évidents. Ne touche PAS au code de
production.
Étape 2 : lance le test et montre-moi qu'il échoue,
avec la sortie réelle.
Étape 3 : implémente le minimum pour le faire passer.
Rien de plus, pas d'abstraction anticipée.
Étape 4 : relance toute la suite et montre-moi qu'elle
est verte.
Attends ma validation entre chaque étape.4 · Les faux indicateurs
Pourquoi la couverture ment
Couvert ≠ vérifié
La couverture mesure les lignes exécutées pendant les tests, pas les comportements vérifiés. Un test sans aucune assertion peut faire monter le chiffre à 100 %.
L’objectif chiffré se triche
Demander « monte la couverture à 90 % » à un agent produit exactement ça : des tests qui traversent le code sans rien affirmer. L’indicateur monte, la sécurité non.
Ce qui compte vraiment
La couverture des chemins critiques et des cas limites. Mieux vaut 40 % bien ciblés sur la logique métier que 95 % diluées sur des getters.
La suite lente est une suite morte
Des tests qui prennent dix minutes ne seront plus lancés. Un agent génère volontiers des tests lourds et redondants : demande explicitement des tests rapides et ciblés.
Le test instable détruit la confiance
Un test qui échoue une fois sur cinq apprend à l’équipe à ignorer les échecs. Un test instable doit être réparé ou supprimé, jamais relancé jusqu’à ce qu’il passe.
Vert n’est pas une preuve
Une suite verte prouve que ce que tu as testé fonctionne. Elle ne dit rien sur ce que tu n’as pas pensé à tester — souvent l’essentiel.
Vérifie que c’est acquis
Tu demandes à ton agent de « monter la couverture de tests à 90 % ». Quel est le risque principal ?
La couverture compte les lignes exécutées, pas les comportements vérifiés. Viser un
pourcentage pousse mécaniquement à produire des tests traversants sans assertion utile.
Demande plutôt la couverture des règles métier et des cas limites, et vérifie qu’un
test sait échouer.
À retenir
Un test qui ne peut pas échouer ne sert à rien
Teste les décisions et les bords, pas les getters. Ajoute systématiquement un test de non-régression après chaque bug. Travaille en TDD dès que le comportement est clair. Et juge tes tests en cassant volontairement ton code, pas en regardant un pourcentage.