Tester ton app vibecodée (sans être un pro du test)

Ton app marche en démo : tu remplis le formulaire, tu cliques, c'est parfait. Puis un vrai utilisateur arrive, soumet un champ vide, double-clique sur « Envoyer », perd sa connexion en plein milieu — et là, ça coince. Bonne nouvelle : tu n'as pas besoin de devenir un pro du test pour couvrir ces cas. L'IA peut écrire les tests et les faire tourner, et c'est ce second point qui change tout.

La démo, c'est le chemin facile

Une démo prouve une seule chose : que ça marche quand tout va bien. Un utilisateur, des données propres, le réseau qui répond, personne qui clique deux fois. C'est le chemin heureux, et le code généré le réussit presque toujours.

Les bugs, eux, vivent sur les bords : l'entrée vide, le format inattendu, le doublon, le double-clic, l'appel réseau qui échoue. Tester, ce n'est rien d'autre que vérifier ces bords automatiquement et à répétition, pour ne pas avoir à recliquer partout à la main à chaque modification.

Et non, ça ne demande pas un diplôme. Un test, c'est juste un bout de code qui dit « quand je fais ça, je dois obtenir ça ». L'IA sait en écrire pour ta stack (Vitest ou Jest pour de la logique JS, Playwright pour piloter un vrai navigateur — l'assistant choisit selon ton projet). Ton rôle change, mais il reste simple — j'y viens.

La vraie astuce : fais TOURNER les tests, pas juste écrire

Voici le cœur du sujet. Demander à l'IA d'écrire des tests, c'est bien. Lui demander de les exécuter, c'est ce qui débloque la boucle qui s'auto-répare.

Un test qui tourne donne à l'IA un signal net : rouge ou vert. Un test rouge, c'est une cible précise — « voici exactement ce qui ne va pas, corrige-le ». Le modèle excelle à ça : écrire le code, lancer les tests, lire l'échec, réparer, relancer, jusqu'au vert. Quand l'assistant peut exécuter npm test lui-même, il boucle tout seul jusqu'à ce que ça passe. C'est radicalement plus fiable que toi en train de juger « à l'œil » si le résultat a l'air bon.

Deux garde-fous honnêtes, parce que ce n'est pas magique :

• L'IA peut tricher — faire passer un test en l'affaiblissant, ou en codant en dur la réponse attendue, plutôt qu'en réparant la vraie logique. Un test du genre expect(true).toBe(true) est vert et ne prouve rien.
• Vert ne veut pas dire « sans bug ». Ça veut dire « ce que j'ai vérifié marche encore ».

D'où le seul réflexe que tu gardes : lis les tests. Pas pour les écrire, pour t'assurer qu'ils vérifient quelque chose de réel. Mon petit truc de pro : casse volontairement le code une seconde et relance — si le test reste vert, c'est qu'il ne teste rien. Un bon test doit virer au rouge quand le code est faux.

Quoi tester en priorité

On ne teste pas tout — viser 100 % de couverture est un piège qui décourage. On teste ce qui ferait mal, et ce qu'on touche souvent.

Dans l'ordre :

1. Le flux central. Les une ou deux choses pour lesquelles ton app existe (s'inscrire, créer un élément, payer). Si ça casse, le reste n'a plus d'importance.
2. Les bords qui piègent le code généré. C'est là que se cachent tes futurs bugs :
   • entrée vide ou manquante (champ vide, rien de sélectionné) ;
   • entrée invalide (mauvais format, nombre négatif, texte énorme) ;
   • doublon (soumettre deux fois la même chose) ;
   • double-clic / double-envoi (la requête part deux fois — deux commandes, deux débits) ;
   • erreur réseau (l'appel échoue ou expire — l'écran plante, se fige, ou gère proprement ?).
3. Tout bug déjà rencontré. Dès que tu corriges un vrai bug, ajoute un test qui le verrouille : c'est le test le plus rentable, il l'empêche de revenir.
4. La logique délicate. Calculs de dates, d'argent, d'arrondis, de permissions — tout ce qui a des « si ». Les fonctions pures (une entrée, une sortie) sont les plus faciles et les plus utiles à tester.

La bonne question à te poser : « qu'est-ce qui me gênerait si un utilisateur tombait dessus dans la première heure ? » Teste ça en premier.

Le réflexe : demande les tests avec la fonctionnalité

Le changement d'habitude qui rend tout ça gratuit : demande les tests en même temps que la fonctionnalité, jamais après. Rajouter des tests sur un code déjà fini, c'est une corvée que tout le monde repousse. Les demander d'emblée, ça ne coûte rien.

Concrètement, ta consigne ressemble à :

Implémente l'ajout d'une tâche. Écris des tests couvrant : champ vide, doublon, double-clic, et un appel réseau qui échoue. Lance-les et corrige jusqu'à ce qu'ils passent.

Deux bénéfices en prime. D'abord, écrire les tests en parallèle pousse le code à être testable — des fonctions plus petites, des entrées/sorties claires. Ensuite, tes tests deviennent une description vivante du comportement attendu : à la prochaine session, l'IA peut les relancer pour réapprendre ce que ton app est censée faire, au lieu de le redeviner. C'est une mémoire qui vit dans le repo, pas dans la conversation.

Garde enfin une habitude simple : lance les tests avant de mettre en ligne. La build qui passe te dit que ça compile ; les tests qui passent te disent que ça marche encore.

En résumé

Tester une app vibecodée ne demande pas d'être expert : ça demande de faire écrire les tests par l'IA, de les faire tourner pour qu'elle se corrige seule, et de garder un œil pour vérifier qu'ils testent vraiment. Commence petit — le flux central, quelques cas limites, un test pour chaque bug rencontré — et demande-les avec chaque fonctionnalité. Laisser l'IA coder vite et prouver que ça tient : c'est exactement ça, vibecoder comme un pro.