La respuesta corta
No añades un archivo de flujo de trabajo, y no escribes un script que extraiga la URL de vista previa de tus logs de compilación. TestSprite se instala como una GitHub App, escucha el evento de despliegue que tu pipeline ya produce, deduce la URL de vista previa a partir de un patrón que defines una sola vez, ejecuta tus pruebas contra ella, y publica el resultado de vuelta como un comentario en el pull request.
La configuración toma unos diez minutos, requiere permisos de administrador para instalar una GitHub App, y no requiere ningún cambio en tu repositorio.
Tu pipeline despliega
Vercel compila el pull request y produce un evento de despliegue en GitHub. TestSprite no compila ni despliega nada por sí mismo.
TestSprite escucha el evento
La GitHub App lo recibe, resuelve la URL objetivo a partir de tu patrón, y comienza la ejecución.
Los resultados llegan al PR
Un comentario con conteos de aprobados/fallidos, pasos fallidos, capturas de pantalla, y un prompt de corrección — además de una verificación requerida opcional que bloquea la fusión.
Requisito previo: confirma que el pull request produce un despliegue
TestSprite se activa a partir de un evento de despliegue, así que ese evento tiene que existir antes de que cualquier otra cosa funcione. Abre cualquier pull request existente y confirma que aparece un despliegue con una URL en la que se puede hacer clic, luego abre esa URL y verifica que el entorno de vista previa realmente carga.
En Vercel esto aparece como un comentario de bot en el pull request que muestra el proyecto, un estado Ready, y un enlace a la vista previa. AWS Amplify, Netlify, y los pipelines autoalojados que crean despliegues de GitHub producen todos la misma señal en su propio formato — lo que importa es que exista un despliegue y que su URL sea accesible.
Paso 1 — conecta GitHub a tu espacio de trabajo
Esta es una configuración única por espacio de trabajo. En TestSprite, ve a Workspace Settings → Integrations, busca la fila de GitHub, y haz clic en Connect. Serás redirigido a GitHub para elegir la organización o cuenta personal propietaria del repositorio, luego elige All repositories u Only select repositories y haz clic en Install & Authorize.
Vale la pena conocer los permisos solicitados antes de aprobarlos:
| Acceso | Alcances |
|---|---|
| Lectura | Actions, checks, issues, metadata |
| Lectura y escritura | Código, estados de commit, despliegues, pull requests |
El acceso de escritura se usa para publicar los resultados de las pruebas de vuelta en tus pull requests y commits. TestSprite no hace push de commits ni modifica tus archivos de flujo de trabajo. Si tu organización no aparece durante la instalación, no tienes permiso para instalar GitHub Apps para ella — un propietario de la organización necesita aprobarlo.
Paso 2 — conecta el repositorio a un proyecto
Abre el proyecto de TestSprite que quieres conectar, ve a la pestaña GitHub Action, y haz clic en Connect GitHub Action. Luego elige cómo deben activarse las pruebas:
| Activador | Ideal para | Dónde aparecen los resultados |
|---|---|---|
| Pull request | Detectar regresiones antes de la fusión | Un comentario en el pull request |
| Push a una rama | Probar un entorno compartido como staging o dev después de cada fusión | Una verificación en el commit |
Un activador es suficiente para empezar. Puedes crear ambos — se ejecutan de forma independiente entre sí.
Paso 3 — elige el evento que significa "despliegue terminado"
Selecciona la pestaña Pull Request, pega la URL de un pull request existente que tenga un despliegue de vista previa funcional, y haz clic en Detect Events. TestSprite lista los eventos de CI/CD que encontró en ese pull request — verificaciones de GitHub Actions, comentarios de bot de Vercel o Amplify, ejecuciones de flujo de trabajo — y eliges cuál inicia una ejecución.
Elige el evento que se dispara después de que el despliegue está activo y la URL es accesible. Esta es la forma más común de configurar mal la instalación: un evento que se dispara al inicio de la compilación ejecutará tus pruebas contra una URL que aún no está lista, y todas las pruebas fallarán.
Paso 4 — completa el patrón de URL objetivo
Cada proveedor de hosting nombra las URL de vista previa de forma diferente, así que le indicas a TestSprite cómo construir la URL para cualquier pull request dado. Hay cinco marcadores de posición disponibles:
| Marcador | Se resuelve en |
|---|---|
{pr} | Número del pull request |
{branch} | Nombre de la rama |
{branch-slug} | Nombre de la rama, apto para URL |
{sha} | SHA completo del commit |
{short-sha} | SHA del commit acortado |
Compara el patrón con una URL de vista previa real, carácter por carácter:
| Tus URL de vista previa se ven así | Ingresa este patrón |
|---|---|
https://app-git-login-fix-team.vercel.app | https://app-git-{branch-slug}-team.vercel.app |
https://pr-123.example.com | https://pr-{pr}.example.com |
Los nombres de host de vista previa predeterminados de Vercel se construyen a partir de la rama, por lo que {branch-slug} suele ser el marcador correcto ahí en lugar de {pr}. Si tu proveedor genera subdominios aleatorios sin nada predecible en ellos, configura una URL de alias estable para el entorno de vista previa y úsala en su lugar.
Un activador de push no necesita ningún patrón en absoluto — se ejecuta contra la URL configurada del entorno de TestSprite que selecciones, así que elige Dev para dev o Production para main.
Paso 5 — envía un evento de prueba antes de guardar
Haz clic en Send Test Event. Esto ejecuta tus pruebas contra el pull request de ejemplo exactamente como lo haría un activador real, para que puedas previsualizar todo el flujo antes de comprometerte con él. Espera unos 30 segundos, luego regresa al pull request en GitHub — aparece un comentario de TestSprite.
Abre la URL de ese comentario antes de continuar. Confirma que es accesible y que apunta al entorno que esperas. Si está mal, corrige el patrón y envía otro evento de prueba en lugar de esperar al siguiente pull request para descubrirlo. Una vez que la ejecución termina, TestSprite actualiza el mismo comentario con el resultado.
Cuando el evento de prueba se ve bien, haz clic en Create Trigger. Aparece en la lista de Triggers marcado como Active y se ejecuta automáticamente en cada pull request futuro. Vale la pena configurar deliberadamente dos opciones activables opcionales:
| Opción | Qué hace |
|---|---|
| Include draft PRs | Ejecuta pruebas en pull requests en borrador además de los listos para revisión |
| Block PR until tests pass | Hace que la verificación de TestSprite sea obligatoria, de modo que las fusiones se bloquean mientras las pruebas están fallando |
Si tu vista previa está detrás de Deployment Protection
Este es el modo de fallo que parece una configuración exitosa. Con Deployment Protection de Vercel activado, cada URL de vista previa está detrás de un muro de autenticación, y un evaluador externo recibe la página de inicio de sesión en lugar de tu aplicación. Las pruebas no arrojan error — describen una página que nadie esperaba.
La verificación del Paso 5 lo detecta: abre la URL del comentario de TestSprite en una ventana privada. Si ves una pantalla de inicio de sesión de Vercel, la protección está activada. Las dos formas de avanzar son deshabilitar la protección para el entorno de vista previa, o usar Protection Bypass for Automation de Vercel, que genera un secreto que Vercel acepta como parámetro de consulta x-vercel-protection-bypass además de como encabezado. Como el patrón de URL objetivo es solo una URL, la forma de parámetro de consulta se le puede añadir:
https://app-git-{branch-slug}-team.vercel.app?x-vercel-protection-bypass=YOUR_SECRETGenera el secreto en Project Settings → Deployment Protection → Protection Bypass for Automation. Sé deliberado con esto — almacena un secreto de bypass en un campo de configuración, así que deshabilitar la protección en entornos de vista previa es la opción más limpia cuando tus vistas previas no contienen nada sensible.
Leer el resultado
Cuando una ejecución termina, TestSprite actualiza su comentario en el pull request — o la verificación del commit — con el resultado. El comentario está estructurado, y la última fila es la que más importa si un agente de IA escribió el código:
| Sección | Qué te indica |
|---|---|
| Resultado principal | Cuántas pruebas pasaron, fallaron, y fueron bloqueadas |
| Puntaje de calidad | Calculado sobre el subconjunto ejecutable de tu suite. Los casos bloqueados se excluyen y se reportan por separado, porque generalmente indican un vacío en el entorno de pruebas más que una regresión del producto |
| Pruebas fallidas | Cada fallo se expande para mostrar qué se esperaba, qué se observó, y una captura de pantalla del momento del fallo |
| Prompt de corrección sugerido | Un prompt listo para copiar que describe la causa raíz probable y la corrección, pensado para pegarse directamente en tu agente de codificación de IA |
Cada resultado enlaza de vuelta al reporte completo en TestSprite.
Verifica tu configuración
Antes de depender de la integración, confirma los cinco puntos:
La integración de GitHub aparece como Connected en tu espacio de trabajo
El repositorio aparece dentro de la pestaña GitHub Action del proyecto
Un trigger está listado y habilitado
Un evento de prueba produjo un comentario de TestSprite (pull request) o una verificación (push)
La URL en ese comentario o verificación abre el entorno desplegado correcto
Solución de problemas
Todas las pruebas fallan y la URL no carga
El trigger se está disparando demasiado pronto — en un evento de inicio de compilación o inicio de flujo de trabajo en lugar de uno de despliegue completado. Edita el trigger y selecciona un evento que se dispare después de que el entorno esté activo.
El comentario muestra la URL equivocada
Compara el patrón de URL con una URL de vista previa real carácter por carácter. Envía otro evento de prueba después de cada cambio en lugar de esperar al siguiente pull request.
No aparecen eventos en Detect Events
El pull request o la rama no tiene eventos de CI/CD registrados, o la GitHub App no tiene acceso a ese repositorio. Confirma que el repositorio esté incluido en la instalación de la app.
Las pruebas se ejecutan contra un entorno obsoleto
Confirma que el evento seleccionado corresponde al despliegue que pretendes probar. Si una rama tiene varios entornos, verifica que la selección de Environment to test coincida.
La organización no aparece listada
No tienes permiso para instalar GitHub Apps para ella. Pide a un propietario de la organización que apruebe la instalación, luego vuelve al Paso 1.
Las pruebas pasan pero la app está rota
Verifica qué sirvió realmente la URL de vista previa. Una vista previa protegida devuelve una página de inicio de sesión que una prueba puede describir sin fallar.
La alternativa de línea de comandos
La GitHub App es la respuesta correcta cuando tu pipeline ya produce despliegues. Si prefieres conducir la ejecución desde tu propio flujo de trabajo — o no estás en GitHub en absoluto — el CLI de código abierto de TestSprite hace el mismo trabajo desde cualquier sistema de CI. Es gratis de instalar y tiene licencia Apache-2.0:
npm install -g @testsprite/testsprite-cli
testsprite setupApunta un proyecto a una URL que ya hayas resuelto, y ejecuta la suite hasta obtener un veredicto:
testsprite project update prj_abc123 --url "$PREVIEW_URL"
testsprite test run --all --project prj_abc123 --wait --output json
# exit 0 = everything passed, exit 1 = something is brokentestsprite ci init github genera un flujo de trabajo para este camino, y el CLI solo necesita TESTSPRITE_API_KEY en el entorno, así que se integra en CircleCI, GitLab, Jenkins, o Azure Pipelines con la misma facilidad. Usa --report junit --report-file <path> para un reporte complementario que esos sistemas ingieren de forma nativa.
Si los flujos que te importan están detrás del propio inicio de sesión de tu aplicación, almacena una cuenta de prueba en el proyecto para que las ejecuciones puedan autenticarse. Ambas opciones son requeridas juntas:
testsprite project update prj_abc123 \
--username qa@example.com \
--password-file ./.secrets/qa-passwordPreguntas frecuentes
¿Necesito añadir un archivo de flujo de trabajo a mi repositorio?
No. La integración se configura enteramente en TestSprite, y no se requiere ningún cambio en tu repositorio.
¿Esto reemplaza mi flujo de trabajo existente de GitHub Actions?
No. TestSprite escucha los eventos que tu flujo de trabajo ya produce — no modifica ni reemplaza tu pipeline.
¿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 crean despliegues de GitHub.
¿Puedo tener tanto un trigger de pull request como uno de push?
Sí. Créalos por separado — se ejecutan de forma independiente entre sí.
¿Qué pasa si mis URL de vista previa no incluyen el número del pull request?
El campo de patrón de URL espera un patrón predecible. Los nombres de host predeterminados de Vercel se construyen a partir de la rama, así que {branch-slug} suele ser el marcador correcto. Si tu proveedor genera subdominios aleatorios, configura una URL de alias estable para el entorno de vista previa y úsala en su lugar.
¿El resultado puede alimentar directamente a mi agente de codificación de IA?
Sí — para eso está la sección Suggested fix prompt del comentario. Es un prompt listo para copiar que describe la causa raíz probable y la corrección, escrito para pegarse en un agente de codificación. Para un ciclo más completo, testsprite setup --agent claude instala una skill de verificación para que el agente pueda crear, ejecutar, y triar pruebas por sí mismo.
¿Cuánto tiempo toma la configuración?
Unos diez minutos, y necesitas permisos de administrador para instalar una GitHub App en la organización propietaria del repositorio.
Tu pipeline ya emite la señal. Escúchala.
Probar un despliegue de vista previa no requiere un nuevo archivo de flujo de trabajo, un script que extraiga logs de compilación, o una acción de terceros para esperar una URL. Tu pipeline ya produce un evento de despliegue; el trabajo consiste en indicarle a TestSprite qué evento significa "en vivo" y cómo construir la URL a partir de él. Diez minutos, sin cambios en el repositorio, y cada pull request se verifica contra un navegador real antes de que un humano lo revise. Para la ruta de línea de comandos, lee la referencia en docs.testsprite.com y marca con una estrella el CLI de código abierto en GitHub.