Un vérificateur pour la boucle, pas un joueur de plus dedans.
Dans Claude Code, Cursor ou Codex, vous ne tapez pas de flags CLI — vous dites simplement : « Configure TestSprite pour ce dépôt et amorce une suite de tests de démarrage, puis lance un smoke test sur le flux le plus important. » L'agent lit vos routes et vos handlers, crée les tests, et les exécute — une seconde passe indépendante sur son propre travail, pas un brouillon de plus à croire aveuglément.
Connecté à 8 agents de codage, directement depuis le CLI
« Configure TestSprite pour ce dépôt et amorce une suite de tests de démarrage »
L'agent lit vos routes, vos handlers et vos flux clés, crée un projet, et rédige environ 8 à 15 tests avec des assertions concrètes et observables — créés en lot, pas tapés un par un.
« Vérifie ce changement avec TestSprite avant de le considérer terminé »
Exécute le test jusqu'à un verdict — succès ou échec — au lieu de s'arrêter à un plan rédigé. Écrire un test n'est pas la même affirmation que l'exécuter.
« Crée un test pour le parcours nominal du paiement et exécute-le jusqu'à un verdict »
Une couverture ciblée pour un flux, à la demande, avec la même discipline « exécute-le, ne te contente pas de le rédiger » que pour la suite complète.
Obtenez ce qu'il vous faut
Le pack d'échec — cause racine, capture d'écran, snapshot du DOM, recommandation de correctif — est du JSON structuré, pour qu'un agent puisse l'analyser et décider de sa prochaine action sans intervention humaine.
You: "Set up TestSprite for this repo and seed a starter test suite,
then smoke-run the most important flow."
# the agent runs this on your behalf — you never type it:
$ testsprite setup
$ testsprite test create-batch starter-suite.json
✓ 11 tests created from your routes and handlers
$ testsprite test run --project prj_8f2a --ids TC_checkout,TC_login --wait
✓ TC_checkout_happy_path passed
✓ TC_login_success passed
« Rédigé » n'est pas « Terminé »
Dites « exécute-le jusqu'à un verdict » et pensez-le vraiment — un plan de test qui existe mais n'a jamais été exécuté ne satisfait pas cette instruction. Seuls un succès ou un échec le font, et chaque échec revient sous forme d'un pack structuré que l'agent peut exploiter lui-même.
Conçu pour les exécutions sans supervision
Lit d'abord votre base de code
La compétence d'onboarding analyse vos routes, vos handlers et vos flux clés avant d'écrire le moindre test — une couverture qui part de ce que votre produit fait réellement, pas d'une supposition.
Score de stabilité
testsprite test flaky <testId> indique à l'agent si un échec est une vraie régression ou un test instable, avant qu'il ne gaspille une tentative de correction sur le mauvais problème.
Version communautaire gratuite
Propose une version communautaire gratuite, pour rester accessible à tous.
Annulation en cours d'exécution
testsprite test cancel <runId> arrête une exécution en cours dès que l'agent — ou vous — décide qu'elle n'est plus nécessaire.
Approuvé par des entreprises du monde entier
"TestSprite offre une génération de cas de test riche, une structure claire et un code facile à lire. Il prend également en charge le débogage en ligne simple avec la possibilité de s'étendre rapidement en générant de nouveaux cas de test."
"L'automatisation de TestSprite nous aide à réduire des tonnes de travail manuel. Les développeurs peuvent facilement détecter et résoudre les bugs plus tôt dans le processus de développement."
FAQ
Que dire concrètement pour configurer tout ça ?
Dans Claude Code, Cursor, ou un autre agent pris en charge : « Configure TestSprite pour ce dépôt et amorce une suite de tests de démarrage, puis lance un smoke test sur le flux le plus important. » L'agent s'occupe du reste — aucun flag à mémoriser.
Que signifie concrètement « amorcer une suite de tests de démarrage » ?
L'agent lit votre base de code — routes, handlers, flux clés — crée un projet TestSprite, rédige environ 8 à 15 tests avec des assertions concrètes et observables, les crée en lot, et n'exécute que les 2 à 3 parcours nominaux les plus importants plutôt que la suite complète.
Pourquoi l'agent de codage ne peut-il pas simplement tester son propre code ?
Il le peut, mais il corrige alors ses propres devoirs — ses tests héritent de tout ce qu'il a mal compris dans les exigences. testsprite s'exécute dans un contexte séparé, en pilotant un vrai navigateur ou en effectuant de vrais appels API, ce qui lui permet de détecter la catégorie de bugs qu'un auto-test ne peut structurellement pas voir.
Comment m'assurer que l'agent ne se contente pas de rédiger un test et de le déclarer terminé ?
Dites « vérifie ce changement avec TestSprite avant de le considérer terminé », ou « exécute-le jusqu'à un verdict ». Cette formulation compte — un plan rédigé mais jamais exécuté ne la satisfait pas, seul un vrai succès ou échec le fait.
Que reçoit l'agent en cas d'échec ?
Un résultat JSON structuré avec un pack complet : étape en échec, capture d'écran, snapshot du DOM, hypothèse de cause racine, recommandation de correctif — tout ce dont il a besoin pour tenter une correction sans d'abord demander à un humain.
Faut-il une CI, ou est-ce que ça marche pour une exécution solo de nuit ?
Les deux fonctionnent. C'est le même CLI, qu'il s'exécute comme étape dans GitHub Actions ou au sein d'une longue session d'agent sur votre propre machine.