Des tests automatisés pour GitHub, sans un fichier de workflow de plus
S'intègre parfaitement à vos éditeurs Android et IA
Aucune modification du dépôt
TestSprite s'installe comme GitHub App et se contente de lire des événements. Il se place à côté de votre pipeline, pas dedans : aucun YAML à écrire, aucun workflow à maintenir, et rien d'ajouté à .github/.
Déclenché par un vrai déploiement
Choisissez l'événement CI/CD qui se déclenche après que l'environnement est en ligne. En choisir un qui part au début de la build est l'erreur de configuration la plus fréquente : tous les tests échouent alors contre une URL qui n'existe pas encore.
Les résultats arrivent sur la pull request
Nombre de tests réussis et en échec, un score de qualité calculé uniquement sur le sous-ensemble exécutable, des captures au moment de l'échec, et un prompt de correction rédigé pour être collé directement dans votre agent de programmation IA.
Une vérification obligatoire qui bloque les fusions
Activez Block PR until tests pass et la vérification TestSprite devient obligatoire : une régression bloque la fusion au lieu de passer et d'être découverte plus tard.
Protégez chaque pull request avec un navigateur réel
Une coche verte devrait signifier que l'application déployée fonctionne, pas qu'une suite a bien été lancée. TestSprite attend le verdict réel et fait échouer le job en cas d'exécution partielle plutôt que de la donner pour bonne.
Conçu pour les équipes qui livrent sur GitHub
Compatible avec votre hébergeur
Tout fournisseur qui signale un déploiement à GitHub et expose une URL joignable : Vercel, AWS Amplify, Netlify, et les pipelines maison qui créent des déploiements GitHub.
Pull request ou push
Un déclencheur de pull request attrape les régressions avant la fusion et commente sur la PR. Un déclencheur de push teste un environnement partagé de préproduction ou de dev après chaque fusion et publie une vérification sur le commit. Créez les deux : ils sont indépendants.
Ou pilotez-le depuis la CLI
Vous préférez maîtriser l'exécution ? La CLI open source fait la même chose depuis n'importe quel CI, et testsprite ci init github génère le workflow pour vous.
Version community gratuite
Nous proposons une version community gratuite, accessible à tous.
Approuvé par des entreprises du monde entier
"Bon travail ! Le MCP de l'équipe TestSprite est vraiment cool ! Pour nos applications Android, le codage IA + les tests IA ferment la boucle et accélèrent les versions stables."
"Pour Android, les tests générés par TestSprite sont propres et fiables. Les flux Appium sont faciles à étendre et à déboguer, et les exécutions planifiées maintiennent une bonne couverture de nos appareils."
"L'automatisation de TestSprite a considérablement réduit notre QA manuelle sur Android. Les développeurs détectent et résolvent les bogues mobiles plus tôt, ce qui maintient notre calendrier de livraison."
FAQ
Dois-je ajouter un fichier de workflow à mon dépôt ?
Non. L'intégration se configure entièrement dans TestSprite et n'exige aucune modification de votre dépôt. Si vous préférez piloter l'exécution depuis votre propre workflow, testsprite ci init github en génère un qui utilise l'action maintenue par TestSprite.
Cela remplace-t-il mon workflow GitHub Actions existant ?
Non. TestSprite écoute des événements que votre workflow produit déjà ; il ne modifie ni ne remplace votre pipeline.
Et si mon dépôt ne produit jamais de déploiement ?
Alors il n'y a rien à écouter. TestSprite se déclenche sur un événement de déploiement : cet événement doit donc exister d'abord. Ajoutez une étape de déploiement à votre pipeline, ou utilisez la CLI dans un workflow et pointez le projet vers une URL que vous résolvez vous-même.
Comment TestSprite connaît-il l'URL de prévisualisation ?
Vous définissez un motif une seule fois, avec des marqueurs résolus à chaque exécution : {pr}, {branch}, {branch-slug}, {sha} et {short-sha}. Ainsi https://pr-123.example.com s'écrit https://pr-{pr}.example.com.
De quelles permissions la GitHub App a-t-elle besoin ?
Lecture sur actions, checks, issues et metadata ; lecture et écriture sur code, commit statuses, deployments et pull requests. C'est le droit d'écriture qui lui permet de publier les résultats sur vos pull requests. TestSprite ne pousse pas de commits et ne modifie pas vos fichiers de workflow.
Les résultats peuvent-ils alimenter un agent de programmation IA ?
Oui. Chaque échec du commentaire de pull request contient un prompt de correction pensé pour être collé dans un agent. Pour une boucle plus complète, testsprite setup --agent claude installe une skill de vérification afin que l'agent crée, exécute et diagnostique les tests lui-même.