Cómo ejecutar pruebas automáticas con GitHub Actions

La integración continua es la práctica de comprobar automáticamente cada cambio en cuanto se sube al repositorio, en lugar de acumular muchos cambios y revisarlos juntos al final. Te conviene porque encuentra los problemas cuando son pequeños y recientes, que es cuando más baratos y fáciles resultan de arreglar. El cambio de fondo respecto de correr las pruebas a mano es la consistencia: una prueba que ejecutás vos, a veces, en tu máquina, depende de que te acuerdes y de que tu entorno esté bien configurado; una prueba que corre sola, siempre, en un entorno limpio y con cada cambio, no depende de nadie y está puesta como red de seguridad todo el tiempo. Nadie puede olvidarse de correrla, y eso es justamente lo que la hace confiable.

Es el archivo que define qué tareas automáticas se ejecutan y cuándo. En GitHub Actions es un archivo en formato YAML que vive dentro del repositorio, en una carpeta reservada para flujos, y tiene tres partes esenciales. La primera define cuándo se dispara, mediante los eventos del repositorio como subir código o abrir una solicitud de cambios. La segunda define dónde corre, especificando un ejecutor, que es una máquina virtual limpia que provee GitHub. Y la tercera define qué hace, mediante una secuencia de pasos que se ejecutan en orden: descargar el código, preparar el entorno, instalar dependencias y correr las pruebas. Cada paso puede ser una acción reutilizable ya publicada o un comando de terminal directo. Como el archivo está versionado junto al código, las reglas evolucionan con el proyecto.

Combinando dos cosas. Primero, un flujo que corra las pruebas ante el evento de solicitud de cambios, de modo que cada solicitud se compruebe antes de integrarse; como los pasos fallan según su código de salida, si una prueba no pasa el flujo entero queda marcado como fallido. Segundo, y esto es lo que realmente frena, las reglas de protección de rama de GitHub: se configura la rama principal para exigir que ese flujo pase como condición obligatoria para permitir la fusión. Con las dos cosas activas, una solicitud con pruebas rotas deja el botón de fusionar bloqueado hasta que se arregle, y el código que rompe algo no llega a la rama de la que sale producción. Sin la regla de protección, el flujo solo avisa del fallo pero no impide integrar el cambio.

En los secretos del repositorio, nunca en el archivo del flujo. El archivo YAML está versionado y a la vista de cualquiera con acceso al código, así que escribir ahí un token o una contraseña equivale a publicarlos. GitHub ofrece un almacén de secretos cifrados en la configuración del repositorio: se guardan ahí y el flujo los referencia por su nombre, de modo que GitHub los inyecta como variables solo en el momento de la ejecución, sin exponer su valor en los registros. Es exactamente la misma regla que rige en cualquier parte del desarrollo: las credenciales no viven en el código ni en los archivos versionados, sino en un mecanismo aparte pensado para protegerlas. Tratar los secretos así desde el principio evita filtraciones que después son muy difíciles de revertir.

Las que sean rápidas y confiables, para que el pipeline de cada cambio dé una respuesta pronta sin volverse un estorbo. Las pruebas unitarias y de integración rápidas, y comprobaciones como las de API o accesibilidad, encajan bien en el flujo que se dispara con cada cambio. Las pruebas lentas o costosas —suites completas de interfaz, pruebas sobre muchos navegadores o dispositivos, pruebas de rendimiento— conviene moverlas a un flujo programado que corra en horarios fijos, para no frenar cada cambio con una espera larga. La razón es práctica: un pipeline que tarda una hora en responder termina saboteado, la gente busca formas de saltárselo y deja de cumplir su función. Decidir qué va en la barrera rápida y qué en los flujos lentos es parte de la estrategia de pruebas del proyecto.

No, sirve para automatizar cualquier tarea que se dispare por un evento del repositorio, aunque ejecutar pruebas es uno de sus usos más frecuentes y el que cubre esta guía. Con la misma mecánica de flujos, eventos y pasos se pueden automatizar despliegues, publicación de paquetes, generación de documentación, revisiones de estilo de código, análisis de seguridad y muchas otras tareas, encadenando la integración continua con la entrega continua. En el mundo DevOps, esos flujos de construcción, prueba y despliegue combinados son lo que se llama un pipeline de CI/CD. Para el enfoque de pruebas, lo importante es dominar primero el patrón básico —correr las pruebas con cada cambio y frenar lo que rompe—, y desde ahí el resto de las automatizaciones son variaciones del mismo esquema.