El CLI No Tiene Que Detenerse en Tu Firewall.
Las redes corporativas restringidas solían significar que las herramientas CLI conectadas a la nube simplemente no funcionaban desde dentro de ellas. El CLI de TestSprite puede configurarse para enrutar su tráfico a través de un proxy corporativo HTTP/HTTPS, así que funciona igual detrás de tu firewall que en cualquier otro lugar.
Integrado en el Mismo CLI que Ya Usas
Se Configura Una Vez, Funciona en Todas Partes
Configura el proxy junto con el resto de tu configuración del CLI, y cada comando — generación de pruebas, reejecuciones, descarga de artefactos — se enruta a través de él automáticamente.
Sin Excepciones de Red Especiales
El CLI llega al sandbox en la nube de TestSprite a través del mismo proxy corporativo que ya usan tus otras herramientas de desarrollo, así que no hay nada nuevo que el equipo de red o seguridad tenga que aprobar.
Funciona en CI, No Solo en Tu Laptop
La configuración puede ejecutarse de forma no interactiva con testsprite setup --from-env --yes --agent <name>, así que la configuración del proxy se traslada limpiamente a los pipelines de CI que corren detrás de la misma política de red.
Las Credenciales Se Gestionan por Separado
La configuración del proxy y las credenciales de proyecto almacenadas vía project credential son independientes, así que cambiar de red no significa volver a ingresar claves de 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.
No Dejes que la Política de Red Decida Qué Puedes Automatizar
Los desarrolladores en empresas con políticas de red restringidas a menudo no pueden usar herramientas CLI conectadas a la nube en absoluto — cada solicitud saliente se bloquea antes de salir del edificio. El soporte de proxy significa que el CLI de TestSprite funciona dentro de esa política en lugar de pedir una excepción a ella.
Diseñado para Equipos Detrás de un Firewall Corporativo
Funciona con Proxies Corporativos Estándar
Se configura a través del propio flujo de configuración del CLI, así que TI no necesita abrir una ruta directa a internet específicamente para TestSprite.
Encaja en los Pipelines de CI Existentes
La configuración no interactiva con testsprite setup --from-env --yes --agent <name> traslada la configuración del proxy a GitHub Actions, GitLab CI, o cualquier runner que esté detrás de la misma política.
Sin una Compilación Enterprise Aparte
El soporte de proxy vive en el mismo CLI que ya instalaste con npm install -g @testsprite/testsprite-cli — no hay nada extra que solicitar o licenciar.
Se Combina con la Gestión de Credenciales
Usa project credential para gestionar las credenciales almacenadas por proyecto, independientemente de cómo el CLI llega al sandbox en la nube de TestSprite.
Con la Confianza de Empresas de Todo el Mundo
"TestSprite ofrece una rica generación de casos de prueba, una estructura clara y un código fácil de leer. También admite la depuración simple en línea con la capacidad de expandirse rápidamente generando nuevos casos de prueba."
"La automatización de TestSprite nos ayuda a reducir toneladas de trabajo manual. Los desarrolladores pueden detectar y resolver errores fácilmente en una etapa más temprana del proceso de desarrollo."
Preguntas Frecuentes
¿El CLI de TestSprite funciona detrás de un proxy corporativo HTTP/HTTPS?
Sí — el soporte de proxy se añadió en la versión v0.3.0 del CLI. El CLI puede configurarse para enrutar su tráfico a través de un proxy corporativo en lugar de llegar directamente al sandbox en la nube de TestSprite.
¿Por qué importa esto si no estoy en una red restringida?
No cambia nada para ti — la configuración del proxy es opcional. Importa para los desarrolladores en empresas donde todo el tráfico saliente tiene que pasar por un proxy aprobado antes de llegar a internet.
¿El soporte de proxy cambia cómo se ejecutan realmente las pruebas?
No. Las pruebas de frontend siguen ejecutándose contra una URL en producción a través de un navegador, y las de backend siguen ejecutándose contra una URL base, ambas en el sandbox en la nube de TestSprite con Auto-Heal para selectores frágiles. El proxy solo cambia cómo el CLI llega a ese sandbox.
¿Cómo configuro el CLI en una red así?
De la misma forma que lo configurarías en cualquier otro lugar — de forma interactiva con testsprite setup, o de forma no interactiva con testsprite setup --from-env --yes --agent <name>, que lee tu clave de API desde la variable de entorno TESTSPRITE_API_KEY.
¿Esto afecta cómo se almacenan las credenciales de mi proyecto?
No — la configuración del proxy y el almacenamiento de credenciales vía project credential se gestionan por separado, así que la forma en que el CLI llega a la red no cambia cómo gestiona las credenciales de tu proyecto.
Tu Política de Red No Debería Bloquear Tu Automatización de Pruebas.
Instala el CLI, apúntalo a tu proxy corporativo, y ejecuta la misma automatización de pruebas en la que tu equipo ya confía — sin pedirle una excepción al equipo de seguridad.