Tests écrits par l'IA :5 000 tests que je n'ai pas écrits

Vous n'avez pas besoin d'écrire des tests pour avoir des tests écrits par l'IA. Traitez les tests comme une fonctionnalité : donnez à l'IA un brief structuré, et elle génère une suite complète en environ 15 minutes. Mon produit compte 5 247 tests. Claude en a écrit 4 722 — 90 %. Voici la méthode exacte, avec le prompt à copier.

Dans l'article précédent, j'ai raconté le bug qui a approuvé 15 candidatures de startups d'un seul clic — celui qui m'a enfin convaincu que les tests sont une assurance, pas une charge. Cet article est l'autre moitié : comment un fondateur solo non technique obtient réellement des milliers de tests sans passer une seule soirée à les écrire.

Tests écrits par l'IA : traitez les tests comme une fonctionnalité, pas comme une corvée

L'erreur que font la plupart des gens est de demander à l'IA : « écris-moi un test pour cette fonction ». On obtient des tests superficiels, décoratifs — du genre qui passent quoi qu'il arrive.

La solution est de donner aux tests le même traitement qu'à la construction d'une fonctionnalité : un brief structuré qui précise quoi tester, quels schémas suivre et comment vérifier le résultat. J'utilise le même format de document que pour les fonctionnalités — la méthode PRP — pointé vers les tests. Un PRP de test prend environ cinq minutes à écrire et produit une couverture qu'un humain qui s'ennuie n'atteindrait jamais.

Un exemple réel : 28 tests en 15 minutes

La semaine dernière, j'ai construit un nouveau service qui gère les témoignages de réussite des anciens de l'accélérateur — les créer, les publier, les archiver. Douze opérations distinctes. L'ancien moi l'aurait livré sans tests et débogué en production. À la place :

Voici la partie à lire deux fois. Sur les deux tests en échec, l'un était une incohérence de nommage dans la mise en place du test — trivial. L'autre a détecté un vrai bug dans mon service : il permettait de publier un témoignage de réussite sans que ses métriques soient renseignées. La suite de tests a trouvé un bug de production avant la production elle-même, dès le premier jour de son existence.

Couverture finale : 94,2 % du service. Écrire ces 28 cas de test à la main aurait pris 3,5 à 4,5 heures. La voie de l'IA a pris 15 minutes — 14 à 18 fois plus vite.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Le prompt de test à copier-coller

Voici le squelette de chaque PRP de test que j'écris. Remplissez les crochets, collez-le dans votre outil de code IA et demandez-lui de générer la suite :

Objectif : une couverture de tests complète pour [nom de la fonctionnalité]. Objectif de couverture : 90 %+.

Fonctionnalité à tester : [le fichier], et la liste de ses opérations — chaque fonction que vous voulez couvrir, par son nom.

Schémas à suivre : collez un ou deux tests bien écrits de votre base de code, pour que l'IA copie votre style au lieu d'en inventer un.

Scénarios à couvrir : le cas nominal ; les cas limites (entrées vides, valeurs manquantes, conditions aux bornes) ; les conditions d'erreur (données invalides, pannes de base de données, accès non autorisé) ; et vos règles métier, écrites en langage simple — « une candidature rejetée ne peut jamais être approuvée », « les utilisateurs ne voient que les données de leur propre organisation ».

Boucle de validation : les commandes exactes pour lancer les tests et vérifier la couverture, afin que l'IA vérifie son propre travail et corrige les échecs avant de vous rendre la main.

Pièges : tout ce qui vous a déjà mordu — changements de statut irréversibles, champs qui doivent exister avant la publication.

La ligne sur les règles métier est celle qui justifie son existence. Chaque règle énoncée en langage simple devient un test qui la garde pour toujours — c'est exactement le genre de test qui aurait attrapé mon bug des 15 approbations.

Pourquoi l'IA teste mieux que les humains

Après avoir généré des milliers de tests de cette façon, je vais dire quelque chose de dérangeant : l'IA est meilleure en test que la plupart des développeurs. Pas plus intelligente — plus minutieuse, pour quatre raisons.

Elle ne s'ennuie pas. Les humains sautent des cas limites parce que « c'est suffisant ». L'IA génère chaque cas que vous précisez, de façon exhaustive.

Elle suit parfaitement les schémas. Montrez-lui un bon test et elle applique le schéma aux douze opérations. Pas d'erreurs de copier-coller, pas de vérifications oubliées.

Elle trouve des cas que vous manqueriez. Sur ma suite des témoignages de réussite, Claude a ajouté des cas limites que je n'avais pas listés : texte vide contre texte absent, nombres négatifs dans les métriques, saisie malveillante dans les filtres de recherche, deux changements de statut contradictoires à la fois.

Elle met à jour les tests quand le code change. Refactorisez le service, relancez le brief, et toute la suite se régénère en quelques minutes. « Les tests sont périmés » cesse d'être une excuse.

Les fonctionnalités demandent de la créativité. Les tests demandent de la minutie. L'IA excelle dans la minutie — c'est pourquoi les tests, plus que la construction de fonctionnalités, sont peut-être son meilleur usage pour un fondateur solo.

Rendez-le automatique

L'état final est simple : chaque fonctionnalité est livrée avec ses tests, générés dans la même session que la fonctionnalité elle-même. Pas de « plus tard ». Pas de sprint de test séparé. Le brief prend cinq minutes, la suite en prend dix, et la boucle de validation fait que l'IA corrige ses propres échecs avant même que vous regardiez.

Depuis que j'ai adopté ce workflow, je n'ai livré aucun bug critique en production en quatre mois — avec 82 % de couverture sur un produit alors que la norme du secteur pour une startup financée est de 60 à 70 %. L'assurance est presque gratuite désormais. La seule décision qui reste est de savoir si vous continuez à la refuser.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Questions fréquentes

Les tests écrits par l'IA sont-ils vraiment bons ?

Avec un brief structuré, oui — souvent meilleurs que ceux écrits à la main, parce que l'IA ne saute pas de cas par ennui. Les miens ont atteint 94,2 % de couverture sur un nouveau service et ont attrapé un vrai bug (publication sans les données requises) avant que la fonctionnalité n'atteigne les utilisateurs. Sans brief, on obtient des tests superficiels — le brief fait la différence.

Qu'est-ce qu'un PRP de test ?

Un court document structuré — cinq minutes à écrire — qui dit à l'IA quoi tester : la fonctionnalité et ses opérations, un exemple de test dont copier le style, les scénarios à couvrir (cas nominal, cas limites, erreurs, règles métier) et les commandes pour vérifier le résultat. Il applique la méthode PRP aux tests.

Combien de temps faut-il pour obtenir une vraie couverture ainsi ?

Environ 15 minutes par fonctionnalité : cinq pour le brief, dix pour la génération et la vérification. La même suite écrite à la main prendrait 3,5 à 4,5 heures — 14 à 18 fois plus. Cet effondrement du coût explique pourquoi mon produit compte 5 247 tests au lieu des zéro qu'il avait avant.

Comment savoir que les tests de l'IA ne sont pas des déchets ?

Deux vérifications. D'abord, la boucle de validation : le brief inclut les commandes pour lancer les tests et le rapport de couverture, donc rien n'est accepté sur la foi. Ensuite, les règles métier : énoncez-les en langage simple et lisez les tests générés pour elles — si « seule la candidature cliquée est approuvée » apparaît comme un test, la suite protège ce qui compte.