Un échec CI ne devrait pas être votre premier indice qu'un réglage cloche.
Avant de brancher TestSprite dans la CI, exécutez testsprite doctor. Il vérifie que votre clé API, votre accès réseau et votre version du CLI sont tous correctement configurés — pour qu'un simple problème de configuration ne se fasse pas passer pour un véritable échec de test.
Intégré au même CLI que vous utilisez déjà
Vérifiez votre clé API
testsprite doctor confirme que votre TESTSPRITE_API_KEY est définie et valide avant qu'un job CI ne consomme sa première exécution sur une erreur d'authentification.
Vérifiez l'accès réseau et proxy
Les proxys d'entreprise et les exécuteurs CI verrouillés peuvent bloquer silencieusement les requêtes sortantes. Doctor confirme que le CLI peut réellement atteindre TestSprite avant que vous ne le découvriez en plein pipeline.
Confirmez votre version du CLI
Un écart de version entre ce qui est installé et ce que votre pipeline attend peut échouer de façons qui ressemblent à un bug produit. Doctor le signale avant que cela n'arrive.
Exécutez-le partout
La même vérification, que vous configuriez en local, branchiez un nouveau job CI, ou déboguiez pourquoi le pipeline d'un collègue ne s'authentifie pas.
$ testsprite doctor Checking environment... ✓ API key found and valid ✓ Network access to TestSprite confirmed ✓ CLI version up to date → environment looks good, ready to run tests $ testsprite doctor Checking environment... ✗ TESTSPRITE_API_KEY not set ✗ Network request blocked — check proxy configuration → fix these before running testsprite test run
Ne laissez pas la CI déboguer votre configuration à votre place
Un pipeline qui échoue avant même d'atteindre vos tests ne teste rien — il échoue simplement bruyamment. Exécuter testsprite doctor en premier transforme « pourquoi la CI vient-elle d'échouer » en une réponse de deux secondes.
Conçu pour brancher TestSprite dans la CI
Exécutez-le avant de brancher la CI
Ajoutez testsprite doctor comme première étape de votre pipeline — juste après l'installation, avant testsprite setup et toute exécution de test réelle.
Se combine avec testsprite setup
Utilisez testsprite setup --from-env --yes --agent <name> pour configurer les identifiants de façon non interactive, puis exécutez doctor pour confirmer qu'ils fonctionnent réellement.
Gratuit et open source
npm install -g @testsprite/testsprite-cli vous donne le CLI. Il est sous licence Apache-2.0, donc rien ne bloque une première vérification.
Sortie lisible par machine
Passez --output json pour obtenir des résultats dans un format que votre pipeline peut analyser et sur lequel il peut agir automatiquement.
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
Que vérifie réellement testsprite doctor ?
Il vérifie que votre clé API est définie et valide, que le CLI peut atteindre TestSprite sur votre réseau — y compris à travers un proxy — et que votre version installée du CLI est à jour.
Quand dois-je l'exécuter ?
Juste après l'installation du CLI, et à nouveau comme première étape de tout nouveau pipeline CI — avant testsprite setup ou une véritable exécution de test, pour qu'un problème de configuration échoue rapidement plutôt qu'en plein pipeline.
En quoi est-ce différent du simple fait d'exécuter un test et de voir ce qui casse ?
Une exécution de test échouée à cause d'une clé API manquante ou d'une requête réseau bloquée ressemble exactement à un véritable échec produit jusqu'à ce que vous creusiez. Doctor distingue « votre configuration est cassée » de « votre produit est cassé » avant que vous ne gaspilliez une exécution sur la mauvaise piste.
Cela fonctionne-t-il en CI, ou seulement en local ?
Les deux — c'est la même commande dans un cas comme dans l'autre. Exécutez-le en local pendant votre configuration, puis à nouveau comme étape CI pour qu'un problème de proxy ou d'identifiants dans l'environnement du pipeline ne passe pas inaperçu.
Que se passe-t-il s'il signale un problème ?
Il vous indique ce qui ne va pas — une TESTSPRITE_API_KEY manquante, un chemin réseau bloqué, ou une version du CLI obsolète — pour que vous puissiez corriger ce seul point au lieu de déboguer une exécution de test qui n'a jamais eu la chance de démarrer.