Exécutez des tests automatiquement à chaque déploiement GitHub.
Connectez un dépôt une seule fois, et TestSprite écoute l'événement GitHub qui signifie « le nouveau build est déployé et l'URL est en ligne » — puis exécute votre suite de tests contre elle et republie le résultat comme commentaire de pull request ou vérification de commit. Aucun fichier de workflow, aucune modification de votre pipeline.
Fonctionne avec tout fournisseur qui déploie vers GitHub
Se déclenche sur votre CI/CD
Un déploiement, une exécution de workflow, ou une vérification de statut — définissez l'événement CI/CD que vous avez déjà comme signal signifiant « prêt à tester ».
Les résultats atterrissent sur la PR
Réussite/échec, étapes en échec, et un lien de relecture sont publiés comme commentaire de PR ou vérification de commit — les relecteurs voient la qualité aux côtés du code.
Bloquez les fusions avec une vérification de statut
Activez « Bloquer la PR jusqu'à ce que les tests passent » et une vérification obligatoire arrête les fusions tant que des régressions sont ouvertes.
Zéro modification de fichier de workflow
Tout est configuré à l'intérieur de TestSprite. Votre dépôt, votre .github/workflows, et votre pipeline existant restent intacts.
1. Votre pipeline CI/CD construit et déploie votre application
→ produit un événement de déploiement dans GitHub
2. TestSprite reçoit cet événement via
l'intégration GitHub App
3. TestSprite résout l'URL cible — à partir du
déploiement lui-même, ou d'un modèle d'URL que vous définissez
(prend en charge {pr}, {branch}, {branch-slug}, {sha})
4. TestSprite exécute vos tests et republie les résultats
sur GitHub comme commentaire de PR ou vérification de commit
Livrez avec un signal auquel vous pouvez faire confiance
Chaque déploiement — un aperçu de PR ou une fusion vers staging — est testé contre l'URL réelle et en ligne. Pas une simulation, pas une supposition.
Deux façons de déclencher une exécution
Pull request
Idéal pour détecter les régressions avant la fusion. TestSprite teste le déploiement d'aperçu de la PR et commente le résultat directement sur la PR.
Push sur une branche
Idéal pour tester un environnement partagé comme staging ou dev après chaque fusion. Les résultats atterrissent comme vérification sur le commit.
Exécutez les deux, indépendamment
Créez un déclencheur PR et un déclencheur push sur le même dépôt — ils s'exécutent selon leurs propres calendriers, sans interférence.
Des suggestions de correctifs prêtes à coller
Chaque échec inclut une suggestion de correctif décrivant la cause probable — copiez-la directement dans votre agent de codage IA.
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
Cela remplace-t-il mon workflow GitHub Actions existant ?
Non. TestSprite écoute les événements que votre workflow produit déjà — un déploiement, un build, une vérification de statut — et y réagit. Il ne modifie ni ne remplace votre pipeline, et aucun fichier de workflow n'est ajouté à votre dépôt.
De quelles permissions la GitHub App a-t-elle besoin ?
Accès en lecture aux Actions, vérifications, issues et métadonnées ; accès en lecture-écriture au code, aux statuts de commit, aux déploiements et aux pull requests. L'accès en écriture sert uniquement à republier les résultats de test comme commentaires de PR ou vérifications de commit — TestSprite ne pousse pas de commits et ne modifie pas les fichiers de workflow.
Quels fournisseurs d'hébergement sont pris en charge ?
Tout fournisseur qui signale un déploiement à GitHub et expose une URL accessible — y compris Vercel, AWS Amplify, Netlify, et les pipelines auto-hébergés qui créent des déploiements GitHub.
Que faire si mes URL d'aperçu utilisent un sous-domaine aléatoire, pas le numéro de PR ?
Le champ de modèle d'URL attend un motif prévisible, utilisant des espaces réservés comme {pr}, {branch}, {branch-slug}, et {sha}. Si votre hébergeur génère des sous-domaines imprévisibles, configurez une URL alias stable pour l'environnement d'aperçu et pointez TestSprite vers celle-ci à la place.
Qu'est-ce qui apparaît dans le résultat ?
Un décompte principal de réussites/échecs/blocages, un score de qualité calculé sur le sous-ensemble exécutable de la suite (les cas bloqués sont rapportés séparément, car ils indiquent généralement une lacune de l'environnement de test plutôt qu'une régression produit), le détail complet attendu-vs-observé avec une capture d'écran pour chaque échec, et une suggestion de correctif prête à copier pour votre agent de codage.
Donnez à chaque déploiement un vrai test, automatiquement.
Connectez un dépôt une seule fois. TestSprite s'occupe du reste — aucun fichier de workflow, aucune modification de votre pipeline, et un commentaire ou une vérification à chaque PR et push.