Utilisé correctement, une IA excelle dans la partie énumération des tests — elle brainstorme les cas limites et écrit rapidement le boilerplate. Mais vous devez vérifier que les assertions sont significatives, car une IA écrira volontiers des tests qui passent sans rien prouver.
Le flux de travail
- Donnez-lui la fonction plus son contrat — ce qu'elle devrait faire, les types d'entrée/sortie, et comment elle devrait gérer les entrées invalides. Les tests ne peuvent pas être meilleurs que la spécification que vous décrivez.
- Demandez explicitement les cas limites — frontières (0, vide, max), et chemins d'erreur (null, négatif, mauvais type), pas seulement le chemin heureux.
- Vérifiez que les assertions sont significatives — un test qui affirme le comportement actuel du code (même s'il est bogué) est inutile. Vérifiez que chaque assertion encode le contrat prévu.
Exemple
// Function under test, with its contract:
// applyDiscount(price, percent) -> price reduced by percent.
// Contract: percent must be 0..100; throws RangeError otherwise. price >= 0.
function applyDiscount(price, percent) {
if (percent < 0 || percent > 100) throw new RangeError('percent out of range');
return price - (price * percent) / 100;
}
// AI-suggested test cases (Jest) — note the edge and error paths, not just happy path:
test('applies a normal discount', () => {
expect(applyDiscount(100, 20)).toBe(80); // happy path
});
test('0% leaves price unchanged', () => {
expect(applyDiscount(100, 0)).toBe(100); // boundary: lower edge
});
test('100% makes it free', () => {
expect(applyDiscount(100, 100)).toBe(0); // boundary: upper edge
});
test('rejects percent above 100', () => {
expect(() => applyDiscount(100, 150)).toThrow(RangeError); // error path
});
L'IA a proposé les cas limites (0 et 100) et le chemin d'erreur que vous pourriez oublier. Votre travail est de confirmer que toBe(80) est la bonne valeur attendue, pas seulement ce que la fonction retourne.
Pourquoi c'est important
La partie difficile des tests n'est pas de taper les blocs test(...) — c'est de penser aux cas que vous auriez sinon oubliés, et une IA est vraiment bonne à cette largeur. Mais elle n'a aucune idée de ce que votre code est censé faire à moins que vous ne le lui disiez, donc sans surveillance elle tend à écrire des tests qui reflètent l'implémentation (ils passent, mais ils passeraient même si la fonction était fausse). Traiter l'IA comme un générateur de cas limites tandis que vous possédez les assertions vous donne une couverture large et une véritable exactitude — la vitesse de l'IA, le jugement de vous.