Verrouillez votre pipeline CI/CD avec un CLI de test IA.
Insérez testsprite dans GitHub Actions, GitLab CI, ou tout pipeline capable d'exécuter une étape shell. Il s'authentifie via une variable d'environnement, exécute votre suite contre un environnement réellement déployé, et se termine avec un code stable et prévisible — pour qu'un build cassé fasse échouer le build, pas le prochain daily standup.
Fonctionne dans n'importe quel CI, exécuteur ou shell
Non interactif par conception
TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude — aucune invite, aucune connexion via navigateur, fonctionne dans un exécuteur headless.
Une étape, n'importe quel pipeline
testsprite test run --all --project <id> --wait --output json en une seule étape CI — analysez le JSON, ou vérifiez simplement le code de sortie.
Des codes de sortie prévisibles
Des codes de sortie stables et documentés permettent à votre pipeline de bloquer un merge sur un résultat réel, sans avoir à analyser des logs en texte libre pour deviner ce qui s'est passé.
Un essai à blanc avant de vous engager
--dry-run exécute la logique de votre pipeline hors ligne avec des données de test, pour que vous puissiez configurer l'étape avant qu'elle ne touche un environnement en production.
# .github/workflows/verify.yml
- name: Verify with TestSprite
env:
TESTSPRITE_API_KEY: ${{ secrets.TESTSPRITE_API_KEY }}
run: |
npm install -g @testsprite/testsprite-cli
testsprite setup --from-env --yes
testsprite test run --all --project prj_8f2a --wait --output json
# exits non-zero on a real failure — the merge gate fails with it
Donnez un vrai sens à votre garde-fou de merge
Un build qui passe parce qu'il n'a jamais vraiment vérifié n'est pas un build qui passe. Chaque exécution du pipeline teste votre environnement réellement déployé — vrai navigateur, vrais appels API — et échoue pour une vraie raison.
Conçu pour chaque étape du pipeline
Pull request, nightly ou release
Exécutez la suite complète à chaque pull request, un sous-ensemble de smoke tests chaque nuit, ou tout avant une release — la même commande, avec un --project et un plan différents.
Relances en lot
testsprite test rerun --all --project <id> revérifie tout après une exécution qui semblait instable, sans redéclencher tout le pipeline.
Version communautaire gratuite
Propose une version communautaire gratuite, pour rester accessible à tous.
Comparez deux exécutions
testsprite test diff <runId1> <runId2> montre exactement ce qui a changé entre un build réussi et un build en échec.
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
Comment le CLI s'authentifie-t-il dans un exécuteur CI headless ?
Définissez TESTSPRITE_API_KEY comme secret, puis exécutez testsprite setup --from-env --yes --agent claude (ou l'agent de votre choix). Aucune invite interactive, aucune connexion via navigateur — c'est conçu exactement pour ça.
Fonctionne-t-il spécifiquement avec GitHub Actions ?
Oui, et avec n'importe quel CI capable d'exécuter une étape shell — GitLab CI, CircleCI, Jenkins, Buildkite. C'est un CLI Node.js installé avec npm ; si votre exécuteur peut faire ça, il peut exécuter TestSprite.
Sur quoi le pipeline se base-t-il réellement ?
Une vraie exécution de tests contre votre environnement déployé — tests navigateur via Playwright, tests d'API avec gestion des dépendances — rapportée avec un code de sortie stable et documenté. Votre étape existante « faire échouer le job si le code n'est pas zéro » fonctionne telle quelle.
Puis-je tester le câblage du pipeline avant qu'il ne soit en production ?
Oui — --dry-run exécute votre logique de test hors ligne contre des données de test, pour que vous puissiez confirmer que l'étape est correctement configurée avant de la pointer vers un environnement réel.
Que se passe-t-il quand la CI détecte une vraie régression ?
Vous obtenez un pack d'échec (étape en échec, capture d'écran, snapshot du DOM, hypothèse de cause racine, recommandation de correctif) attaché à cette exécution — récupérez-le avec testsprite test failure get <testId> depuis les logs du job ou une étape suivante.