Cómo usar Checksum para las pruebas continuas de extremo a extremo en CI/CD

Ejecutar pruebas de extremo a extremo (E2E) en CI/CD solo funciona si tu conjunto de pruebas puede evolucionar junto con tu aplicación. A medida que tu producto cambia, crear manualmente nuevas pruebas y corregir las que se rompen puede convertirse rápidamente en el cuello de botella que ralentiza cada lanzamiento.

Checksum está diseñado para automatizar gran parte de ese proceso. 

Esta guía te muestra cómo conectar Checksum a tu entorno y repositorio, generar y ejecutar pruebas de Playwright en tu canal de CI/CD y habilitar el mantenimiento autónomo a medida que tu aplicación evoluciona.

Cómo Checksum admite las pruebas E2E continuas

Checksum admite las pruebas E2E continuas mediante un flujo de trabajo continuo:

1. Configuración: conecta tu repositorio y entorno de pruebas.
2. Detección: analiza tu aplicación e identifica los flujos de usuario más importantes que deben probarse.
3. Generación: crea pruebas de Playwright listas para producción y las entrega como solicitudes de incorporación de cambios a tu repositorio.
4. Ejecución: ejecuta esas pruebas localmente o en tu canal de CI/CD, mientras la recuperación automática intenta resolver los fallos temporales durante la ejecución.
5. Corrección: actualiza las pruebas de Playwright que se hayan roto cuando cambia tu aplicación y abre una solicitud de incorporación de cambios con la corrección propuesta.
6. Supervisión: realiza un seguimiento del estado de las pruebas y avisa a tu equipo cuando los problemas requieren atención.

Como cada prueba es código estándar de Playwright, conservas la propiedad total y puedes ejecutar el conjunto de pruebas con o sin Checksum.

Requisitos previos para las pruebas E2E continuas en Checksum

Antes de configurar Checksum para las pruebas E2E continuas, asegúrate de que lo siguiente esté listo.

Un entorno de ensayo o similar al de producción

Checksum realiza pruebas contra una aplicación activa, por lo que necesitarás un entorno de ensayo o similar al de producción accesible con una URL del entorno. Si tu aplicación requiere autenticación, configura una URL de inicio de sesión y proporciona las credenciales de un usuario de prueba que Checksum pueda utilizar para iniciar sesión y analizar los flujos de usuario de tu aplicación.

Un repositorio y un canal de CI conectados

Conecta tu repositorio de GitHub o GitLab para que Checksum pueda analizar tu base de código y crear solicitudes de incorporación de cambios que contengan pruebas de Playwright generadas o actualizadas. Si tus pruebas se encuentran en un repositorio independiente, conectar tanto el repositorio de código fuente como el repositorio de pruebas mejora la precisión de la detección de flujos.

También necesitarás una plataforma de CI para ejecutar las pruebas. Checksum ofrece compatibilidad integrada con GitHub Actions y GitLab CI/CD, mientras que otras plataformas de CI pueden integrarse mediante la CLI de Checksum o la API pública.

Un proyecto y una clave de API de Checksum

Crea un proyecto de Checksum en la aplicación web y genera una clave de API del proyecto desde Configuración del proyecto. La clave de API autentica la CLI de Checksum y permite que tu canal de CI descargue las variables de entorno necesarias para ejecutar las pruebas.

Si quieres una explicación más detallada del proceso de configuración inicial, también puedes visitar {{deeplink:154034:la página de introducción a Checksum:getting_started}}.

Cómo realizar pruebas E2E continuas en Checksum

Los pasos siguientes presuponen que has creado un proyecto de Checksum y tienes a mano tu clave de API.

Paso 1. Conecta tu entorno y repositorio

En el asistente de configuración de la aplicación web, establece la URL del entorno (por ejemplo, https://staging.myapp.com) y la URL de inicio de sesión, y añade las credenciales del usuario de prueba con las que Checksum se autenticará. 

A continuación, instala la aplicación de Git para GitHub o GitLab para que Checksum pueda leer tu código y abrir solicitudes de incorporación de cambios. Si tus pruebas se alojarán junto al código fuente, conecta el mismo repositorio para ambos.

Paso 2. Inicializa tu repositorio de pruebas

Crea (o designa) un repositorio para tus pruebas e inicialízalo con la CLI:

mkdir my-checksum-tests && cd my-checksum-tests
npm init -y
npm install @checksum-ai/runtime playwright
npx checksumai init

Esto crea una carpeta checksum/ con la configuración, una configuración de Playwright y una prueba de ejemplo. Verifica la conexión antes de continuar:

npm install
npx playwright install --with-deps
npx checksumai dotenv --download --api-key=<YOUR_API_KEY>
npx checksumai test -g "example"

La prueba de ejemplo confirma que el inicio de sesión funciona en tu entorno. Un resultado correcto significa que estás listo para detectar flujos reales.

Paso 3. Deja que el agente detecte los flujos de usuario críticos

Inicia una sesión de detección y deja que el agente E2E analice tu aplicación para identificar los flujos de usuario importantes. Una vez completada la detección, revisa los flujos propuestos y prioriza los más relevantes para tu lanzamiento antes de generar las pruebas.

Paso 4. Genera pruebas de Playwright listas para producción

Genera pruebas de Playwright para los flujos que seleccionaste. 

El agente planifica, implementa, revisa y verifica cada prueba antes de abrir una solicitud de incorporación de cambios que contiene un archivo de historia legible para personas y la prueba de Playwright. 

Revisa la solicitud de incorporación de cambios como cualquier otro cambio de código y, después, fusiona las pruebas que estés listo para añadir a tu conjunto.

Paso 5. Integra las pruebas en tu canalización de CI/CD

Para GitHub Actions, guarda tu clave de API y los valores del entorno como secretos del repositorio y, después, añade un flujo de trabajo que instale Playwright, descargue el archivo de entorno de Checksum y ejecute el conjunto de pruebas:

name: Ejecutar pruebas de Checksum
on:
workflow_dispatch:        # activador manual para iniciar
# schedule:
#   - cron: '0 0 * * *'   # ejecución nocturna, una vez verificado
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Instalar dependencias de npm
run: npm install
- name: Instalar Playwright con dependencias
run: npx playwright install --with-deps
- name: Descargar .env desde Checksum
run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
- name: Ejecutar pruebas de Checksum
run: npx checksumai test
env:
CHECKSUM_API_KEY: ${{ secrets.CHECKSUM_API_KEY }}
USERNAME: ${{ secrets.USERNAME }}
PASSWORD: ${{ secrets.PASSWORD }}
LOGIN_URL: ${{ secrets.LOGIN_URL }}
BASE_URL: ${{ secrets.BASE_URL }}
CI: true

GitLab CI/CD sigue la misma estructura en .gitlab-ci.yml . Comienza con un activador manual ( workflow_dispatch / when: manual ) para confirmar que la ejecución funciona correctamente y, después, pasa a una programación para comprobaciones nocturnas del estado o a un activador de fusión para verificar el funcionamiento después de las implementaciones.

Paso 6. Añade ejecuciones por solicitud de incorporación de cambios y activa la reparación autónoma

Si quieres que Checksum ejecute las pruebas para cada solicitud de incorporación de cambios, utiliza la acción oficial de GitHub en lugar de ejecutar la CLI en tu propio ejecutor. Esto resulta útil para validar los cambios introducidos en cada solicitud de incorporación de cambios.

name: Pruebas de Checksum
on: pull_request
permissions:
contents: read
pull-requests: read
jobs:
checksum:
runs-on: ubuntu-latest
steps:
- uses: checksum-ai/test-run-action@v1
with:
api-key: ${{ secrets.CHECKSUM_API_KEY }}
grep: 'checkout'
auto-heal: true

La opción grep filtra las pruebas que se ejecutan por nombre, mientras que auto-heal: true activa la reparación automática cuando falla una prueba. 

De forma predeterminada, el flujo de trabajo finaliza después de aceptar la ejecución y publica los resultados como comentario en la solicitud de incorporación de cambios. Si quieres que el flujo de trabajo espere al resultado final y termine correctamente o con error según corresponda, establece wait: true.

Con la recuperación automática habilitada, Checksum intenta recuperarse en tiempo real durante la ejecución de la prueba. Si la prueba sigue fallando, actualiza la prueba de Playwright, abre una solicitud de incorporación de cambios con la corrección propuesta y publica el progreso como comentario en la solicitud de incorporación de cambios original. 

Después, tu equipo puede revisar y fusionar los cambios como cualquier otra contribución de código.

Cómo es una implementación exitosa de pruebas E2E continuas

Una vez que Checksum se integre en tu canalización de CI/CD, deberías esperar ver lo siguiente:

• Tu conjunto de pruebas E2E se ejecuta automáticamente según el activador que hayas configurado, incluidas las solicitudes de incorporación de cambios, las ejecuciones programadas y las implementaciones.
• Se detectan nuevos flujos de usuario y se convierten en pruebas de Playwright sin tener que escribir manualmente cada prueba.
• Los fallos de las pruebas causados por cambios en la aplicación se resuelven mediante recuperación automática o reparación automática antes de requerir actualizaciones manuales.
• Tu equipo dedica menos tiempo al mantenimiento de las pruebas de Playwright y más tiempo a revisar cambios de pruebas relevantes entregados mediante solicitudes de incorporación de cambios.

Para medir el estado de tu implementación, supervisa la tasa de aprobación de las pruebas, el porcentaje de pruebas reparadas automáticamente, el tiempo medio de resolución de los fallos de las pruebas y la tasa de falsos positivos. 

Estas métricas te ayudan a comprender con qué fiabilidad se ejecuta tu conjunto E2E a medida que evoluciona tu aplicación. Para comparar tus resultados con los valores de referencia de producción, Informe de referencia de calidad de Checksum proporciona datos para estas métricas basados en más de 1 millón de ejecuciones reales en producción.

Errores comunes en las pruebas E2E continuas y consejos profesionales

Incluso con la configuración adecuada, algunos errores comunes pueden afectar a la calidad, la ejecución y el mantenimiento de las pruebas. Estas son las cuestiones a las que debes prestar atención y cómo evitarlas.

Ejecutar pruebas en un entorno inestable

Si los resultados de tus pruebas son incoherentes o fallan antes de que comience una ejecución significativa, es posible que tu entorno de pruebas no esté listo. Asegúrate de que tu entorno de preparación o similar al de producción sea estable, de que las credenciales del usuario de prueba funcionen correctamente y de que la prueba de ejemplo se apruebe antes de generar cobertura adicional.

Generar demasiados flujos de usuario

Checksum puede identificar más flujos de usuario de los que necesitas inicialmente. Generar pruebas para cada candidato aumenta el tiempo de ejecución y el esfuerzo de revisión. Comienza con los flujos de trabajo más importantes para tus versiones y amplía la cobertura con el tiempo.

Fusionar pruebas generadas sin revisarlas

Las pruebas generadas y reparadas se entregan como solicitudes de incorporación de cambios para que tu equipo pueda validar cada cambio antes de que pase a formar parte del conjunto de pruebas. Revisa cuidadosamente las pruebas nuevas durante las primeras etapas de adopción y desarrolla confianza en el proceso de generación con el tiempo.

Automatizar tu canalización demasiado pronto

Antes de programar ejecuciones o activar pruebas para cada solicitud de incorporación de cambios, confirma que tu canalización sea estable mediante ejecuciones manuales. Cuando obtengas resultados fiables de forma constante, podrás automatizar el flujo de trabajo con mayor confianza.

Bloquear todas las solicitudes de incorporación de cambios

Habilitar wait: true hace que el flujo de trabajo espere a que finalice la ejecución de la prueba antes de completarse. Úsalo únicamente en los flujos de trabajo que deban bloquear una fusión. Para todo lo demás, el comentario predeterminado en la solicitud de incorporación de cambios proporciona información sin ocupar los ejecutores de CI.

Conclusión

Ya has visto cómo encaja Checksum en un flujo de trabajo de pruebas E2E continuas: desde conectar tu entorno y repositorio hasta generar pruebas de Playwright, integrarlas en tu canalización de CI/CD y habilitar el mantenimiento autónomo. 

A medida que evoluciona tu aplicación, Checksum ayuda a mantener la fiabilidad de tu conjunto de pruebas E2E sin añadir el mismo nivel de mantenimiento manual.

Si quieres explorar más a fondo la plataforma, puedes leer nuestro análisis detallado de Checksum para obtener más información sobre sus capacidades, o comprobar cómo funciona Checksum con tu propia aplicación conectando directamente con su equipo.

Preguntas frecuentes

¿Soy propietario de las pruebas que genera Checksum?

Sí. Checksum genera pruebas estándar de Playwright que se incorporan a tu repositorio, por lo que puedes leerlas, editarlas y ejecutarlas con o sin Checksum.

¿Qué sucede cuando cambia la interfaz de usuario y una prueba falla?

Checksum intenta primero recuperar automáticamente la prueba durante su ejecución. Si el problema no se puede resolver, la corrección automática actualiza la prueba de Playwright y abre una solicitud de incorporación de cambios para que tu equipo la revise.

¿Checksum se ejecuta en mi infraestructura o en la de Checksum?

Se admiten ambas opciones. Puedes ejecutar la CLI en tu propio ejecutor de CI o usar la acción de GitHub para que Checksum ejecute las pruebas.

¿En qué se diferencia Checksum de un servicio de pruebas gestionado?

Un servicio de pruebas gestionado depende de personas para crear y mantener tus pruebas. Checksum automatiza gran parte de ese trabajo al generar y mantener pruebas de Playwright directamente en tu propia canalización de CI/CD.

¿Puede Checksum trabajar junto con las pruebas que ya tengo?

Sí. Checksum funciona con tus pruebas de Playwright existentes, cubre las carencias de cobertura y genera pruebas nuevas a medida que evoluciona tu aplicación.