Ejecuta pruebas automáticamente en cada despliegue de GitHub.
Conecta un repositorio una vez, y TestSprite espera el evento de GitHub que significa "el nuevo build está desplegado y la URL está activa" — luego ejecuta tu suite de pruebas contra ella y publica el resultado como comentario en el pull request o como commit check. Sin archivo de workflow, sin cambios en tu pipeline.
Funciona con cualquier proveedor que despliegue en GitHub
Se activa con tu CI/CD
Un despliegue, una ejecución de workflow o un status check — define el evento de CI/CD que ya tienes como la señal de que algo está "listo para probar".
Los resultados aparecen en el PR
Aprobado/fallido, los pasos que fallaron y un enlace de repetición se publican como comentario en el PR o como commit check — los revisores ven la calidad junto al código.
Bloquea fusiones con un status check
Activa la opción "Bloquear el PR hasta que las pruebas pasen" y un check obligatorio detiene las fusiones mientras haya regresiones abiertas.
Cero cambios en archivos de workflow
Todo se configura dentro de TestSprite. Tu repositorio, tu .github/workflows y tu pipeline existente permanecen intactos.
1. Tu pipeline de CI/CD construye y despliega tu
aplicación → produce un evento de despliegue en GitHub
2. TestSprite recibe ese evento a través de la
integración de GitHub App
3. TestSprite resuelve la URL de destino — a partir del
propio despliegue, o de un patrón de URL que definas
(admite {pr}, {branch}, {branch-slug}, {sha})
4. TestSprite ejecuta tus pruebas y publica los resultados
en GitHub como comentario en el PR o como commit check
Lanza con una señal en la que puedas confiar
Cada despliegue — una vista previa de PR o una fusión a staging — se prueba contra la URL real y activa. Ni una simulación, ni una suposición.
Dos formas de activar una ejecución
Pull request
Ideal para detectar regresiones antes de fusionar. TestSprite prueba la vista previa de despliegue del PR y comenta el resultado directamente en el PR.
Push a una rama
Ideal para probar un entorno compartido como staging o dev después de cada fusión. Los resultados aparecen como un check en el commit.
Ejecuta ambos, de forma independiente
Crea un disparador de PR y uno de push en el mismo repositorio — se ejecutan según sus propios horarios, sin interferir entre sí.
Prompts de corrección, listos para pegar
Cada fallo incluye un prompt de corrección sugerido que describe la causa raíz probable — cópialo directamente en tu agente de codificación con IA.
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
¿Esto reemplaza mi workflow existente de GitHub Actions?
No. TestSprite escucha eventos que tu workflow ya produce — un despliegue, un build, un status check — y reacciona a ellos. No modifica ni reemplaza tu pipeline, y no se añade ningún archivo de workflow a tu repositorio.
¿Qué permisos necesita la GitHub App?
Acceso de lectura a Actions, checks, issues y metadatos; acceso de lectura y escritura a código, estados de commit, despliegues y pull requests. El acceso de escritura se usa solo para publicar los resultados de las pruebas como comentarios en el PR o como commit checks — TestSprite no envía commits ni modifica archivos de workflow.
¿Qué proveedores de hosting son compatibles?
Cualquier proveedor que reporte un despliegue a GitHub y exponga una URL accesible — incluyendo Vercel, AWS Amplify, Netlify y pipelines autoalojados que creen despliegues de GitHub.
¿Qué pasa si mis URLs de vista previa usan un subdominio aleatorio, no el número de PR?
El campo de patrón de URL espera un patrón predecible, usando marcadores como {pr}, {branch}, {branch-slug} y {sha}. Si tu proveedor genera subdominios impredecibles, configura una URL alias estable para el entorno de vista previa y apunta TestSprite a esa en su lugar.
¿Qué aparece en el resultado?
Un conteo principal de aprobadas/fallidas/bloqueadas, una puntuación de calidad calculada sobre el subconjunto ejecutable de la suite (los casos bloqueados se reportan por separado, ya que normalmente indican un vacío en el entorno de pruebas y no una regresión del producto), el detalle completo de lo esperado frente a lo observado con una captura de pantalla para cada fallo, y un prompt de corrección listo para copiar para tu agente de codificación.
Dale a cada despliegue una prueba real, automáticamente.
Conecta un repositorio una vez. TestSprite se encarga del resto — sin archivo de workflow, sin cambios en tu pipeline, y un comentario o check en cada PR y push.