Nuevo: ¡TestSprite CLI ya está disponible!

Bloquea Tu Pipeline de CI/CD Con un CLI de Pruebas con IA.

Añade testsprite a GitHub Actions, GitLab CI, o cualquier pipeline que ejecute un paso de shell. Se autentica desde una variable de entorno, ejecuta tu suite contra un entorno real desplegado, y termina con un código estable y predecible — así un build roto hace fallar el build, no la próxima reunión de equipo.

Funciona en Cualquier CI, Cualquier Ejecutor, Cualquier Shell

GitHub ActionsGitLab CICircleCIJenkinsCualquier ejecutor de shell
Un pipeline en verde que nunca llegó a abrir el sitio ni llamó a la API no es un pipeline en verde — es una suposición. testsprite se ejecuta en el mismo paso que tu build, contra un entorno real desplegado, y le da al gate de fusión algo verídico que comprobar.

No Interactivo por Diseño

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude — sin prompts, sin inicio de sesión por navegador, funciona en un ejecutor sin interfaz.

Un Paso, Cualquier Pipeline

testsprite test run --all --project <id> --wait --output json como un único paso de CI — analiza el JSON, o simplemente revisa el código de salida.

Códigos de Salida Predecibles

Códigos de salida estables y documentados significan que tu pipeline puede bloquear una fusión basándose en un resultado real, no en analizar logs de texto libre para adivinar qué pasó.

Simulacro Antes de Confirmar

--dry-run ejercita la lógica de tu pipeline sin conexión, con datos de prueba, para que puedas conectar el paso antes de que apunte a un entorno real.

# .github/workflows/verify.yml
- name: Verify with TestSprite
  env:
    TESTSPRITE_API_KEY: ${{ secrets.TESTSPRITE_API_KEY }}
  run: |
    npm install -g @testsprite/testsprite-cli
    testsprite setup --from-env --yes
    testsprite test run --all --project prj_8f2a --wait --output json

# exits non-zero on a real failure — the merge gate fails with it

Haz Que el Gate de Fusión Signifique Algo

Un build que pasa porque nunca comprobó nada de verdad no es un build que pasa. Cada ejecución del pipeline prueba tu entorno real desplegado — navegador real, llamadas de API reales — y falla por una razón real.

Diseñado para Cada Etapa del Pipeline

PR, Nocturno, o Release

Ejecuta la suite completa en cada PR, un conjunto de humo más pequeño cada noche, o todo antes de un release — el mismo comando, distinto --project y plan.

Reintentos en Lote

testsprite test rerun --all --project <id> reverifica todo después de una ejecución que parece inestable, sin volver a disparar todo el pipeline.

Versión Comunitaria Gratuita

Ofrece una versión comunitaria gratuita, haciéndonos accesibles para todos.

Compara Dos Ejecuciones

testsprite test diff <runId1> <runId2> muestra exactamente qué cambió entre un build que pasó y uno que falló.

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

¿Cómo se autentica el CLI en un ejecutor de CI sin interfaz?

Define TESTSPRITE_API_KEY como un secreto, luego ejecuta testsprite setup --from-env --yes --agent claude (o el agente de tu elección). Sin prompt interactivo, sin inicio de sesión por navegador — está diseñado exactamente para esto.

¿Funciona específicamente con GitHub Actions?

Sí, y con cualquier CI que pueda ejecutar un paso de shell — GitLab CI, CircleCI, Jenkins, Buildkite. Es un CLI de Node.js instalado con npm; si tu ejecutor puede hacer eso, puede ejecutar TestSprite.

¿Sobre qué bloquea realmente el pipeline?

Una ejecución de prueba real contra tu entorno desplegado — pruebas de navegador vía Playwright, pruebas de API con manejo de dependencias — reportada con un código de salida estable y documentado. Tu paso existente de "fallar el job si no es cero" simplemente funciona.

¿Puedo probar la conexión del pipeline antes de que esté en producción?

Sí — --dry-run ejercita tu lógica de pruebas sin conexión, contra datos de prueba, para que puedas confirmar que el paso está bien conectado antes de apuntarlo a un entorno real.

¿Qué pasa cuando el CI detecta una regresión real?

Obtienes un paquete de fallo (paso que falló, captura de pantalla, instantánea del DOM, hipótesis de causa raíz, recomendación de corrección) adjunto a esa ejecución — obtenlo con testsprite test failure get <testId> desde los logs del job o un paso posterior.

Dale a Tu Pipeline Algo Real Sobre Qué Bloquear.