Le CLI n'a pas à s'arrêter à votre pare-feu.
Un réseau d'entreprise verrouillé signifiait autrefois que les outils CLI connectés au cloud ne fonctionnaient tout simplement pas depuis l'intérieur. Le CLI TestSprite peut être configuré pour faire transiter son trafic par un proxy HTTP/HTTPS d'entreprise, pour qu'il fonctionne derrière votre pare-feu exactement comme partout ailleurs.
Intégré au même CLI que vous utilisez déjà
Configuré une fois, fonctionne partout
Configurez le proxy en même temps que le reste de votre configuration CLI, et chaque commande — génération de tests, relances, récupération d'artefacts — y transite automatiquement.
Aucune exception réseau particulière
Le CLI atteint le bac à sable cloud de TestSprite via le même proxy d'entreprise que vos autres outils de développement utilisent déjà, donc rien de nouveau à faire approuver par une équipe réseau ou sécurité.
Fonctionne en CI, pas seulement sur votre poste
La configuration peut s'exécuter de façon non interactive avec testsprite setup --from-env --yes --agent <name>, pour que la configuration du proxy se propage proprement dans les pipelines CI qui tournent derrière la même politique réseau.
Les identifiants restent gérés séparément
La configuration du proxy et les identifiants de projet stockés via project credential sont indépendants, donc changer de réseau ne signifie pas ressaisir vos clés API.
$ testsprite doctor Checking CLI environment... Node.js version — OK Network connectivity — OK (via corporate proxy) TESTSPRITE_API_KEY — found $ testsprite setup --from-env --yes --agent claude Reading TESTSPRITE_API_KEY from environment... Corporate proxy detected — routing CLI traffic through it Setup complete.
Ne laissez pas la politique réseau décider de ce que vous pouvez automatiser
Dans les entreprises aux politiques réseau verrouillées, les développeurs ne peuvent souvent utiliser aucun outil CLI connecté au cloud — chaque requête sortante est bloquée avant même de quitter le bâtiment. Le support du proxy permet au CLI TestSprite de fonctionner dans le cadre de cette politique, au lieu de demander une exception.
Conçu pour les équipes derrière un pare-feu d'entreprise
Fonctionne avec les proxys d'entreprise standards
Configuré via le propre flux de configuration du CLI, pour que l'équipe IT n'ait pas besoin d'ouvrir un accès direct à internet spécifiquement pour TestSprite.
S'intègre aux pipelines CI existants
La configuration non interactive avec testsprite setup --from-env --yes --agent <name> propage la configuration du proxy dans GitHub Actions, GitLab CI, ou tout exécuteur derrière la même politique.
Pas de build entreprise séparé
Le support du proxy vit dans le même CLI que vous avez déjà installé avec npm install -g @testsprite/testsprite-cli — rien de plus à demander ou à licencier.
Se combine avec la gestion des identifiants
Utilisez project credential pour gérer les identifiants stockés par projet, indépendamment de la façon dont le CLI atteint le bac à sable cloud de TestSprite.
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
Le CLI TestSprite fonctionne-t-il derrière un proxy HTTP/HTTPS d'entreprise ?
Oui — le support du proxy a été ajouté dans la version v0.3.0 du CLI. Le CLI peut être configuré pour faire transiter son trafic par un proxy d'entreprise plutôt que d'atteindre directement le bac à sable cloud de TestSprite.
Pourquoi est-ce important si je ne suis pas sur un réseau verrouillé ?
Cela ne change rien pour vous — la configuration du proxy est optionnelle. Elle compte pour les développeurs des entreprises où tout le trafic sortant doit passer par un proxy approuvé avant même d'atteindre internet.
Le support du proxy change-t-il la façon dont les tests s'exécutent réellement ?
Non. Les tests frontend s'exécutent toujours contre une URL en production via un navigateur, et les tests backend s'exécutent toujours contre une URL de base, tous deux exécutés dans le bac à sable cloud de TestSprite avec Auto-Heal pour les sélecteurs fragiles. Le proxy change seulement la façon dont le CLI atteint ce bac à sable.
Comment configurer le CLI sur un réseau de ce type ?
De la même façon que partout ailleurs — en mode interactif avec testsprite setup, ou en mode non interactif avec testsprite setup --from-env --yes --agent <name>, qui lit votre clé API depuis la variable d'environnement TESTSPRITE_API_KEY.
Cela affecte-t-il la façon dont mes identifiants de projet sont stockés ?
Non — la configuration du proxy et le stockage des identifiants via project credential sont gérés séparément, donc la façon dont le CLI atteint le réseau ne change pas la façon dont il gère les identifiants de votre projet.
Votre politique réseau ne devrait pas bloquer votre automatisation de tests.
Installez le CLI, pointez-le vers votre proxy d'entreprise, et exécutez la même automatisation de tests sur laquelle votre équipe compte déjà — sans demander d'exception à la sécurité.