Automatizar pruebas end to end con GitHub Actions te permite validar cada commit en un servidor de integración continua, sin depender de tu máquina local. Aquí verás cómo configurar un workflow YAML que clona el repositorio, instala dependencias, levanta una base de datos Postgres como servicio y ejecuta tus pruebas con cada push o pull request.

Esta guía es útil si ya tienes una suite de pruebas funcionando en local con mocking, seeds y base de datos aislada, y quieres dar el siguiente paso: que las pruebas corran solas en cada contribución.

Por qué automatizar pruebas en integración continua

Cuando corres npm run endtoend en tu máquina, validas tu código en ese momento. Pero ¿qué pasa cuando otro desarrollador hace un commit? Ahí entra la integración continua: un servidor que corre las mismas pruebas automáticamente con cada push, sin que nadie tenga que recordarlo.

El beneficio es directo. Cada contribución queda marcada con un check verde si pasa las pruebas, o con una X si algo se rompió. Eso te da una señal visual inmediata sobre la salud del código antes de hacer merge.

¿Qué es GitHub Actions? Es el motor de automatización integrado en GitHub que ejecuta workflows definidos en archivos YAML cada vez que ocurre un evento en el repositorio, como un push o un pull request.

Cómo se estructura el archivo YAML del workflow

El primer paso es crear la carpeta .github/workflows al mismo nivel que src, y dentro un archivo como api-continuous-integration.yaml [02:08]. El nombre del archivo no importa, mientras sea YAML válido.

Dentro defines tres bloques clave:

• name: identificador legible del workflow, por ejemplo API CI.
• on: los eventos que disparan la ejecución, como push en cualquier rama o pull_request hacia main.
• jobs: las tareas que se van a ejecutar, como correr pruebas unitarias, end to end o un linter.

Cada job necesita un sistema operativo base. Lo común es usar ubuntu-latest y una imagen de Node, en este caso Node 16 [04:55], porque es donde corren las pruebas.

Qué pasos necesita el job para correr las pruebas

Piensa en una máquina desde cero. ¿Qué le falta para ejecutar tu suite? Esa es la lógica que sigues paso a paso:

1. Checkout del repositorio con actions/checkout@v3, que clona el código en el commit específico.
2. Instalación de dependencias con npm ci, una variante de npm install optimizada para entornos de integración continua [06:30].
3. Ejecución de pruebas corriendo el script definido en package.json.

Cómo manejar variables de entorno en el workflow

Aquí aparece un detalle importante. En local usas un archivo .env.endtoend para cargar configuración, pero ese archivo está ignorado por Git y no existe en el servidor.

La solución es enviar las variables de entorno directamente desde el YAML usando la clave env dentro del paso. El formato cambia: en lugar de = usas : con espacio.

¿Por qué crear una variable de entorno CI separada? Porque si reutilizas NODE_ENV=endtoend, el archivo de configuración intentará cargar un .env.endtoend que no existe en el servidor. Al usar NODE_ENV=ci, el config no encuentra archivo y toma las variables directamente de la máquina.

Esto requiere agregar un nuevo script en package.json, por ejemplo endtoend:ci, que ejecute las pruebas con la variable NODE_ENV=ci [09:40]. Así el archivo config no busca ningún .env, sino que lee las variables que GitHub Actions inyectó al contenedor.

Cómo levantar Postgres como servicio en GitHub Actions

La pregunta clave: si en local usas Docker Compose para levantar Postgres, ¿cómo lo replicas en el servidor? GitHub Actions soporta services, que funcionan al estilo Docker dentro del job [11:30].

Defines un servicio así:

• Nombre del servicio, por ejemplo postgres_endtoend.
• Imagen oficial, en este caso postgres.
• Variables de entorno bajo la clave env (no environment como en Docker Compose).
• Puerto estándar 5432, sin necesidad de cambiarlo porque no hay otra instancia compitiendo.

Por qué localhost no funciona y qué usar en su lugar

En tu máquina te conectas a localhost porque Docker hace binding del puerto al sistema anfitrión. En GitHub Actions no existe ese localhost: la conexión usa la red interna de contenedores.

Esto significa que el host de conexión debe ser el nombre del servicio, no localhost. Si llamaste al servicio postgres_endtoend, esa es la cadena que va en la variable de host. Si pones localhost, simplemente no encuentra la base de datos.

Cómo verificar que el workflow funciona

Al hacer push, GitHub muestra el estado del workflow en la vista de commits. Entras al detalle y ves cada paso ejecutándose: checkout, instalación de dependencias, ejecución de pruebas [13:55].

GitHub Actions oculta automáticamente user y password con asteriscos en los logs, lo cual es una protección útil cuando dejas un console.log de configuración para depurar.

Cuando todas las pruebas pasan, aparece un check verde junto al commit. Si algo falla, aparece una X. Esa señal visual te dice si la contribución está validada o si rompió el sistema.

Este mismo patrón existe en otras plataformas. GitLab tiene su propio motor de CI, Bitbucket Pipelines ofrece algo equivalente, y la lógica de pasos, servicios y variables de entorno se repite con sintaxis distinta.

¿Cómo estás automatizando tus pruebas hoy? Cuéntame en los comentarios qué stack usas y qué retos te has encontrado al mover tus end to end de local a un servidor de integración continua.