Vous avez construit une recette. Le prompt semble correct. Vous l’avez exécutée une fois avec une entrée soigneusement rédigée et la sortie avait l’air bien. Prêt à déployer ?
Pas si vite. Une entrée n’est pas une suite de tests. La recette peut gérer votre exemple soigneusement écrit parfaitement et s’effondrer sur les entrées désordonnées, incomplètes et contradictoires que les vrais utilisateurs envoient. Déployer sans test systématique est un pari — et la plupart des équipes ne réalisent les probabilités que quand quelque chose casse en production.
Tester ma recette élimine les conjectures. Générez des entrées réalistes, exécutez la recette contre chacune et regardez les résultats arriver en streaming avant de vous engager sur quoi que ce soit.
Le problème des tests manuels
La plupart des équipes testent les recettes de la même manière : taper une entrée, lancer l’exécution, lire la sortie, répéter. Cette approche a trois problèmes.
C’est lent. Taper des entrées à la main, attendre chaque résultat et évaluer mentalement la qualité prend des minutes par test. Tester 20 variations prend une heure que vous n’avez pas.
C’est biaisé. Vous écrivez des entrées basées sur ce que vous pensez que les utilisateurs enverront. Votre modèle mental de la distribution des entrées est faux — il l’est toujours. Les vraies entrées incluent des fautes de frappe, des champs manquants, des instructions contradictoires et des cas limites que vous n’avez jamais imaginés.
Ce n’est pas reproductible. Il n’y a pas de trace de ce que vous avez testé, quels étaient les résultats, ou si la recette s’est améliorée après votre dernière modification de prompt. Chaque cycle de test repart de zéro.
Générer des entrées réalistes
Cliquez sur le bouton Tester la recette sur la page de détail de n’importe quelle recette et JieGou génère des entrées de test synthétiques pour vous. La génération utilise le schéma d’entrée de la recette — noms de champs, types, descriptions et exemples que vous avez fournis — pour produire N variations réalistes (configurable de 5 à 50).
Les entrées générées ne sont pas du bruit aléatoire. Elles couvrent le spectre réaliste : entrées bien formées, cas limites avec un minimum d’information, entrées avec des exigences contradictoires et entrées qui poussent les limites de ce pour quoi la recette a été conçue. Pensez-y comme un ingénieur QA automatisé qui lit les spécifications de votre recette et rédige des cas de test.
Vous pouvez revoir les entrées générées avant le début de l’exécution. Supprimez celles qui ne sont pas pertinentes, modifiez d’autres pour cibler des scénarios spécifiques, ou ajoutez vos propres entrées personnalisées à l’ensemble. L’objectif est une suite de tests qui reflète la réalité, pas un exercice synthétique.
Streaming en temps réel avec NDJSON
Une fois que vous lancez l’exécution de test, JieGou exécute la recette contre chaque entrée séquentiellement. Les résultats arrivent en streaming dans votre navigateur en temps réel via NDJSON (JSON délimité par des retours à la ligne) — chaque ligne est un objet JSON complet représentant un événement.
Le TestMyRecipeModal progresse à travers quatre phases :
- Idle — Prêt à configurer et démarrer
- Generating — Les entrées synthétiques sont en cours de création
- Running — La recette s’exécute contre chaque entrée, avec les résultats qui arrivent en streaming
- Complete — Tous les tests sont terminés, le résumé est disponible
Pendant la phase Running, vous voyez les résultats arriver un par un. Pas d’attente que le lot entier soit terminé. Pas de spinner cachant toute la progression derrière un seul état de chargement. Chaque résultat apparaît dès que son exécution est complète, vous pouvez donc commencer à lire les sorties pendant que les tests suivants sont encore en cours.
C’est important pour les recettes qui prennent plus de temps. Si votre recette appelle des API externes ou traite des documents longs, les exécutions individuelles peuvent prendre 10 à 30 secondes. Sans streaming, tester 20 entrées signifie fixer un spinner pendant plusieurs minutes. Avec le streaming NDJSON, vous examinez le premier résultat en quelques secondes.
Lire les résultats
Quand l’exécution de test se termine, la vue des résultats vous donne deux niveaux de détail.
Les statistiques résumées montrent la vue d’ensemble en un coup d’oeil : total de tests exécutés, nombre de succès, nombre d’échecs, temps d’exécution moyen et utilisation moyenne de tokens. Si 18 des 20 tests ont réussi mais 2 ont échoué, vous savez immédiatement que la recette a des lacunes à combler.
Les accordéons par test vous permettent de creuser dans chaque exécution individuelle. Dépliez n’importe quel test pour voir l’entrée envoyée, la sortie complète retournée, le temps d’exécution, le comptage de tokens et les messages d’erreur éventuels. La comparaison côte à côte de l’entrée et de la sortie facilite le jugement sur la compréhension de la requête par la recette et la production d’un résultat utile.
La combinaison fonctionne comme les suites de tests de code : le résumé vous dit si quelque chose ne va pas, et les détails vous disent quoi et où.
Intégration de la piste d’audit
Chaque exécution de test est journalisée comme une action d’audit recipe.tested. L’enregistrement d’audit capture qui a lancé le test, quand, quelle recette a été testée, combien d’entrées ont été générées et la ventilation succès/échec.
Cela sert deux objectifs. Premièrement, cela crée une piste de responsabilité pour les équipes avec des exigences de conformité — vous pouvez démontrer que les recettes ont été testées avant le déploiement. Deuxièmement, cela vous donne un historique de l’activité de test. Quand une recette commence à mal fonctionner en production, vous pouvez vérifier le journal d’audit pour voir quand elle a été testée pour la dernière fois et à quoi ressemblaient les résultats.
Les enregistrements d’audit sont visibles dans le Hub Opérations aux côtés d’autres activités du système, de sorte que les tests font partie de la même visibilité opérationnelle que l’exécution, les approbations et les changements de configuration.
Pourquoi c’est important pour la confiance en production
Le fossé entre « ça a marché quand je l’ai essayé » et « ça fonctionne de manière fiable à grande échelle » est là où la plupart des échecs d’automatisation IA se produisent. Une recette peut gérer 90 % des entrées parfaitement mais produire des résultats absurdes pour les 10 % restants. Sans test systématique, ce taux d’échec de 10 % ne devient visible qu’après que de vrais utilisateurs le rencontrent.
Tester ma recette comble ce fossé en rendant rapide et facile l’exécution d’une suite de tests significative avant chaque déploiement. Générez des entrées, regardez les résultats arriver en streaming, examinez le résumé, corrigez les problèmes et testez à nouveau. Le cycle entier prend des minutes, pas des heures.
Combiné avec Quality Guard pour le monitoring continu et les bakeoffs pour la comparaison de prompts, Tester ma recette complète le cycle de vie qualité : testez avant de déployer, comparez quand vous expérimentez, surveillez après avoir livré.
Tester ma recette est disponible sur tous les plans. Essayez maintenant.