De vrais tests de navigateur dans votre pipeline GitLab CI
S'intègre parfaitement à vos éditeurs Android et IA
Deux variables, aucun fichier de configuration
Définissez TESTSPRITE_API_KEY comme variable CI/CD masquée et la CLI s'authentifie depuis l'environnement. Rien n'est écrit dans ~/.testsprite, ce qui est exactement ce que l'on veut sur un runner éphémère.
Aucun navigateur sur votre runner
L'exécution a lieu dans le cloud de TestSprite contre de vrais navigateurs : le job n'installe que la CLI. Cela supprime l'étape la plus lente d'un pipeline à froid — télécharger ou mettre en cache des binaires de navigateur.
Un JUnit que GitLab affiche
--report junit --report-file <chemin> écrit le rapport. Pointez artifacts:reports:junit dessus et GitLab affichera les résultats test par test dans le widget de la merge request.
Le code de sortie fait la barrière
--wait bloque jusqu'à ce que toutes les exécutions soient terminales : un code 0 signifie donc que tous les tests ont réellement réussi, pas qu'ils ont bien été lancés. Les codes documentés distinguent un test en échec (1) d'un problème d'authentification (3) ou d'un solde épuisé (12).
Protégez la merge request avec un navigateur réel
Les tests unitaires confirment que le code fait ce pour quoi il a été écrit. Seule une exécution contre votre review app confirme que ce que vous vous apprêtez à fusionner fonctionne.
Conçu pour les équipes qui livrent sur GitLab
Compatible avec les review apps
Pointez le projet vers l'URL de la review app avant l'exécution : testsprite project update <id> --url "$CI_ENVIRONMENT_URL". La suite ne change pas même si la cible bouge à chaque merge request.
Figez la version
Installez @testsprite/testsprite-cli@<version> plutôt que de suivre latest, pour qu'une nouvelle release ne change jamais le comportement de votre pipeline sans commit.
Frontend et backend en une seule barrière
Regroupez les parcours web et les tests de contrat d'API dans une liste de tests et exécutez-la avec testsprite testlist run, en fixant chaque projet à son environnement.
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
L'intégration GitHub App fonctionne-t-elle avec GitLab ?
Non : cette intégration écoute les événements de déploiement GitHub et est propre à GitHub. Sur GitLab, vous pilotez l'exécution depuis votre pipeline avec la CLI, qui n'a besoin que de TESTSPRITE_API_KEY dans l'environnement.
Comment afficher les résultats dans la merge request ?
Écrivez le rapport avec --report junit --report-file testsprite-junit.xml et déclarez-le sous artifacts:reports:junit. GitLab affichera alors les résultats test par test dans le widget de la merge request.
Comment tester une review app dont l'URL change à chaque fois ?
Mettez à jour l'URL du projet à la première étape du job avec la variable de GitLab : testsprite project update <id> --url "$CI_ENVIRONMENT_URL". La suite reste la même pendant que la cible bouge.
Et si mon application exige une connexion ?
Enregistrez un compte de test sur le projet avec --username et --password-file ; les deux options sont obligatoires ensemble. Sans elles, l'exploration et les exécutions ne voient que les pages publiques, et cela produit un avertissement, pas un échec.
La CLI est-elle open source ?
Oui : la CLI open source est sous licence Apache-2.0 et s'installe gratuitement depuis npm. Elle requiert Node 20.19+, 22.13+ ou 24+. L'exécution des tests a lieu dans le cloud et consomme des crédits d'espace de travail.
Puis-je essayer des commandes sans dépenser de crédits ?
Oui. --dry-run parcourt tout le chemin de code hors ligne avec des données préparées, et test scaffold et test lint ne touchent ni au réseau ni à vos identifiants.