La réponse courte
Vous n'ajoutez pas de fichier de workflow, et vous n'écrivez pas de script qui extrait l'URL de prévisualisation de vos logs de build. TestSprite s'installe comme une GitHub App, écoute l'événement de déploiement que votre pipeline produit déjà, déduit l'URL de prévisualisation à partir d'un modèle que vous définissez une seule fois, exécute vos tests contre celle-ci, et republie le résultat sous forme de commentaire sur la pull request.
La mise en place prend environ dix minutes, nécessite des droits d'administration pour installer une GitHub App, et ne requiert aucune modification de votre dépôt.
Votre pipeline déploie
Vercel construit la pull request et produit un événement de déploiement dans GitHub. TestSprite ne construit ni ne déploie rien lui-même.
TestSprite entend l'événement
La GitHub App le reçoit, résout l'URL cible à partir de votre modèle, et démarre l'exécution.
Les résultats arrivent sur la PR
Un commentaire avec le nombre de réussites/échecs, les étapes en échec, des captures d'écran, et une invite de correction — plus un contrôle requis optionnel qui bloque la fusion.
Prérequis : confirmez que la pull request produit un déploiement
TestSprite se déclenche sur un événement de déploiement, cet événement doit donc exister avant que quoi que ce soit d'autre ne fonctionne. Ouvrez une pull request existante et confirmez qu'un déploiement est listé avec une URL cliquable, puis ouvrez cette URL et vérifiez que l'environnement de prévisualisation se charge réellement.
Sur Vercel, cela apparaît sous forme de commentaire de bot sur la pull request listant le projet, un statut Ready, et un lien vers la prévisualisation. AWS Amplify, Netlify, et les pipelines auto-hébergés qui créent des déploiements GitHub produisent tous le même signal dans leur propre format — ce qui compte, c'est qu'un déploiement existe et que son URL soit accessible.
Étape 1 — connectez GitHub à votre espace de travail
C'est une configuration unique par espace de travail. Dans TestSprite, allez dans Workspace Settings → Integrations, trouvez la ligne GitHub, et cliquez sur Connect. Vous serez redirigé vers GitHub pour choisir l'organisation ou le compte personnel propriétaire du dépôt, puis choisissez All repositories ou Only select repositories et cliquez sur Install & Authorize.
Les permissions demandées valent la peine d'être connues avant de les approuver :
| Accès | Portées |
|---|---|
| Lecture | Actions, checks, issues, métadonnées |
| Lecture et écriture | Code, statuts de commit, déploiements, pull requests |
L'accès en écriture sert à republier les résultats de test sur vos pull requests et commits. TestSprite ne pousse pas de commits et ne modifie pas vos fichiers de workflow. Si votre organisation n'apparaît pas lors de l'installation, vous n'avez pas la permission d'installer des GitHub Apps pour elle — un propriétaire d'organisation doit l'approuver.
Étape 2 — connectez le dépôt à un projet
Ouvrez le projet TestSprite que vous voulez connecter, allez dans l'onglet GitHub Action, et cliquez sur Connect GitHub Action. Choisissez ensuite comment les tests doivent être déclenchés :
| Déclencheur | Idéal pour | Où les résultats apparaissent |
|---|---|---|
| Pull request | Détecter les régressions avant la fusion | Un commentaire sur la pull request |
| Push sur une branche | Tester un environnement partagé comme staging ou dev après chaque fusion | Un check sur le commit |
Un seul déclencheur suffit pour démarrer. Vous pouvez créer les deux — ils s'exécutent indépendamment l'un de l'autre.
Étape 3 — choisissez l'événement qui signifie « déploiement terminé »
Sélectionnez l'onglet Pull Request, collez l'URL d'une pull request existante ayant un déploiement de prévisualisation fonctionnel, et cliquez sur Detect Events. TestSprite liste les événements CI/CD qu'il a trouvés sur cette pull request — checks GitHub Actions, commentaires de bot de Vercel ou Amplify, exécutions de workflow — et vous choisissez celui qui démarre une exécution.
Choisissez l'événement qui se déclenche après que le déploiement est en ligne et que l'URL est accessible. C'est l'erreur de configuration la plus courante : un événement qui se déclenche au démarrage du build exécutera vos tests contre une URL qui n'est pas encore prête, et chaque test échouera.
Étape 4 — renseignez le modèle d'URL cible
Chaque fournisseur d'hébergement nomme les URL de prévisualisation différemment, vous indiquez donc à TestSprite comment construire l'URL pour n'importe quelle pull request donnée. Cinq espaces réservés sont disponibles :
| Espace réservé | Se résout en |
|---|---|
{pr} | Numéro de la pull request |
{branch} | Nom de la branche |
{branch-slug} | Nom de la branche, adapté aux URL |
{sha} | SHA complet du commit |
{short-sha} | SHA raccourci du commit |
Faites correspondre le modèle à une véritable URL de prévisualisation, caractère par caractère :
| Vos URL de prévisualisation ressemblent à | Saisissez ce modèle |
|---|---|
https://app-git-login-fix-team.vercel.app | https://app-git-{branch-slug}-team.vercel.app |
https://pr-123.example.com | https://pr-{pr}.example.com |
Les noms d'hôte de prévisualisation par défaut de Vercel sont construits à partir de la branche, c'est pourquoi {branch-slug} est généralement l'espace réservé approprié ici plutôt que {pr}. Si votre hébergeur génère des sous-domaines aléatoires sans rien de prévisible, configurez une URL d'alias stable pour l'environnement de prévisualisation et utilisez-la à la place.
Un déclencheur de push n'a besoin d'aucun modèle — il s'exécute contre l'URL configurée de l'environnement TestSprite que vous sélectionnez, choisissez donc Dev pour dev ou Production pour main.
Étape 5 — envoyez un événement de test avant d'enregistrer
Cliquez sur Send Test Event. Cela exécute vos tests contre la pull request d'exemple exactement comme le ferait un vrai déclencheur, afin que vous puissiez prévisualiser tout le flux avant de vous y engager. Attendez environ 30 secondes, puis retournez sur la pull request GitHub — un commentaire TestSprite apparaît.
Ouvrez l'URL de ce commentaire avant d'aller plus loin. Confirmez qu'elle est accessible et pointe vers l'environnement attendu. Si elle est incorrecte, corrigez le modèle et envoyez un autre événement de test plutôt que d'attendre la prochaine pull request pour le découvrir. Une fois l'exécution terminée, TestSprite met à jour le même commentaire avec le résultat.
Lorsque l'événement de test semble correct, cliquez sur Create Trigger. Il apparaît dans la liste Triggers marqué Active et s'exécute automatiquement sur chaque future pull request. Deux bascules optionnelles méritent d'être réglées délibérément :
| Bascule | Ce qu'elle fait |
|---|---|
| Include draft PRs | Exécute les tests sur les pull requests en brouillon en plus de celles prêtes pour la revue |
| Block PR until tests pass | Rend le check TestSprite obligatoire, bloquant ainsi les fusions tant que les tests échouent |
Si votre prévisualisation est protégée par Deployment Protection
C'est le mode d'échec qui ressemble à une configuration réussie. Avec Deployment Protection de Vercel activée, chaque URL de prévisualisation se trouve derrière un mur d'authentification, et un testeur externe reçoit la page de connexion au lieu de votre application. Les tests ne génèrent pas d'erreur — ils décrivent une page que personne n'attendait.
La vérification de l'étape 5 le détecte : ouvrez l'URL du commentaire TestSprite dans une fenêtre privée. Si vous voyez un écran de connexion Vercel, la protection est activée. Les deux solutions sont de désactiver la protection pour l'environnement de prévisualisation, ou d'utiliser Protection Bypass for Automation de Vercel, qui génère un secret que Vercel accepte à la fois comme paramètre de requête x-vercel-protection-bypass et comme en-tête. Comme le modèle d'URL cible n'est qu'une URL, la forme en paramètre de requête peut y être ajoutée :
https://app-git-{branch-slug}-team.vercel.app?x-vercel-protection-bypass=YOUR_SECRETGénérez le secret sous Project Settings → Deployment Protection → Protection Bypass for Automation. Soyez délibéré sur ce point — cela stocke un secret de contournement dans un champ de configuration, donc désactiver la protection sur les environnements de prévisualisation est l'option la plus propre lorsque vos prévisualisations ne contiennent rien de sensible.
Lire le résultat
Lorsqu'une exécution se termine, TestSprite met à jour son commentaire de pull request — ou son check de commit — avec le résultat. Le commentaire est structuré, et la dernière ligne est celle qui compte le plus si un agent IA a écrit le code :
| Section | Ce qu'elle vous indique |
|---|---|
| Résultat principal | Combien de tests ont réussi, échoué, et été bloqués |
| Score de qualité | Calculé sur le sous-ensemble exécutable de votre suite. Les cas bloqués sont exclus et rapportés séparément, car ils indiquent généralement un écart d'environnement de test plutôt qu'une régression produit |
| Tests en échec | Chaque échec se déploie pour montrer ce qui était attendu, ce qui a été observé, et une capture d'écran du moment de l'échec |
| Invite de correction suggérée | Une invite prête à copier décrivant la cause probable et la correction, destinée à être collée directement dans votre agent de codage IA |
Chaque résultat renvoie vers le rapport complet dans TestSprite.
Vérifiez votre configuration
Avant de vous fier à l'intégration, confirmez les cinq points suivants :
L'intégration GitHub apparaît comme Connected dans votre espace de travail
Le dépôt apparaît dans l'onglet GitHub Action du projet
Un déclencheur est listé et activé
Un événement de test a produit un commentaire TestSprite (pull request) ou un check (push)
L'URL de ce commentaire ou check ouvre le bon environnement déployé
Dépannage
Chaque test échoue et l'URL ne se charge pas
Le déclencheur se déclenche trop tôt — sur un événement de démarrage de build ou de workflow plutôt que sur un événement de fin de déploiement. Modifiez le déclencheur et sélectionnez un événement qui se déclenche après que l'environnement est en ligne.
Le commentaire affiche la mauvaise URL
Vérifiez le modèle d'URL par rapport à une véritable URL de prévisualisation, caractère par caractère. Envoyez un autre événement de test après chaque modification plutôt que d'attendre la prochaine pull request.
Aucun événement n'apparaît dans Detect Events
La pull request ou la branche n'a aucun événement CI/CD enregistré, ou la GitHub App n'a pas accès à ce dépôt. Confirmez que le dépôt est inclus dans l'installation de l'app.
Les tests s'exécutent contre un environnement obsolète
Confirmez que l'événement sélectionné correspond au déploiement que vous voulez tester. Si une branche a plusieurs environnements, vérifiez que la sélection Environment to test correspond.
L'organisation n'est pas listée
Vous n'avez pas la permission d'installer des GitHub Apps pour elle. Demandez à un propriétaire d'organisation d'approuver l'installation, puis retournez à l'étape 1.
Les tests réussissent mais l'application est cassée
Vérifiez ce que l'URL de prévisualisation a réellement servi. Une prévisualisation protégée renvoie une page de connexion qu'un test peut décrire sans échouer.
L'alternative en ligne de commande
La GitHub App est la bonne réponse lorsque votre pipeline produit déjà des déploiements. Si vous préférez piloter l'exécution depuis votre propre workflow — ou si vous n'êtes pas du tout sur GitHub — le TestSprite CLI open source fait le même travail depuis n'importe quel système CI. Il est gratuit à installer et sous licence Apache-2.0 :
npm install -g @testsprite/testsprite-cli
testsprite setupPointez un projet vers une URL que vous avez déjà résolue, et exécutez la suite jusqu'au verdict :
testsprite project update prj_abc123 --url "$PREVIEW_URL"
testsprite test run --all --project prj_abc123 --wait --output json
# exit 0 = everything passed, exit 1 = something is brokentestsprite ci init github échafaude un workflow pour ce chemin, et le CLI n'a besoin que de TESTSPRITE_API_KEY dans l'environnement, il s'intègre donc tout aussi facilement dans CircleCI, GitLab, Jenkins, ou Azure Pipelines. Utilisez --report junit --report-file <path> pour un fichier annexe que ces systèmes ingèrent nativement.
Si les flux qui vous importent se trouvent derrière le système de connexion propre à votre application, stockez un compte de test sur le projet pour que les exécutions puissent s'authentifier. Les deux options sont requises ensemble :
testsprite project update prj_abc123 \
--username qa@example.com \
--password-file ./.secrets/qa-passwordFoire aux questions
Dois-je ajouter un fichier de workflow à mon dépôt ?
Non. L'intégration se configure entièrement dans TestSprite, et aucune modification de votre dépôt n'est requise.
Cela remplace-t-il mon workflow GitHub Actions existant ?
Non. TestSprite écoute les événements que votre workflow produit déjà — il ne modifie ni ne remplace votre pipeline.
Quels fournisseurs d'hébergement sont pris en charge ?
Tout fournisseur qui rapporte 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.
Puis-je avoir à la fois un déclencheur pull request et un déclencheur push ?
Oui. Créez-les séparément — ils s'exécutent indépendamment l'un de l'autre.
Que faire si mes URL de prévisualisation n'incluent pas le numéro de la pull request ?
Le champ de modèle d'URL attend un modèle prévisible. Les noms d'hôte par défaut de Vercel sont construits à partir de la branche, donc {branch-slug} est généralement l'espace réservé approprié. Si votre hébergeur génère des sous-domaines aléatoires, configurez une URL d'alias stable pour l'environnement de prévisualisation et utilisez-la à la place.
Le résultat peut-il alimenter directement mon agent de codage IA ?
Oui — c'est à cela que sert la section Invite de correction suggérée du commentaire. C'est une invite prête à copier décrivant la cause probable et la correction, rédigée pour être collée dans un agent de codage. Pour une boucle plus complète, testsprite setup --agent claude installe une compétence de vérification afin que l'agent puisse lui-même créer, exécuter et trier les tests.
Combien de temps prend la mise en place ?
Environ dix minutes, et vous avez besoin de droits d'administration pour installer une GitHub App sur l'organisation propriétaire du dépôt.
Votre pipeline émet déjà le signal. Écoutez-le.
Tester un déploiement de prévisualisation ne nécessite pas de nouveau fichier de workflow, de script qui extrait les logs de build, ou d'action tierce pour attendre une URL. Votre pipeline produit déjà un événement de déploiement ; le travail consiste à indiquer à TestSprite quel événement signifie « en ligne » et comment construire l'URL à partir de celui-ci. Dix minutes, aucune modification de dépôt, et chaque pull request est vérifiée face à un vrai navigateur avant qu'un humain ne la regarde. Pour le chemin en ligne de commande, lisez la référence sur docs.testsprite.com et mettez une étoile au CLI open source sur GitHub.