Automatizar pruebas con GitHub Actions en un proyecto Go te permite ejecutar tests cada vez que alguien hace push, sin depender de comandos manuales. Aquí verás cómo dejar listo un workflow YAML que sincroniza dependencias y corre go test en cada rama, ideal si trabajas con módulos Go y quieres integrar CI desde el primer commit.

¿Cómo resolver inconsistencias en las dependencias de Go?

Antes de tocar GitHub Actions, conviene dejar el proyecto limpio. En Go, las dependencias viven en la carpeta vendor, y cuando cambias de rama o eliminas librerías sin limpiar, aparecen warnings en rojo que rompen la compilación [00:14].

La secuencia para sincronizar es directa:

• go mod vendor para actualizar el contenido del vendor.
• go mod tidy para depurar dependencias no usadas.
• Mantener la carpeta vendor dentro del .gitignore para no versionarla.

¿Qué hace go mod vendor? Copia todas las dependencias declaradas en el go.mod a una carpeta local llamada vendor, para que el proyecto compile sin descargar nada externo.

¿Cómo escribir una prueba dummy en Go con testify?

Para validar que el pipeline funciona, no necesitas una prueba sofisticada. Basta con un test mínimo que confirme un valor [01:30]. El estándar en Go es nombrar el archivo con el sufijo _test.go, así el compilador lo identifica como archivo de pruebas.

En este caso se usa el submódulo require de testify, que detiene la ejecución si una aserción falla. Lo traes con go get y luego lo importas en tu archivo:

go package main

import ( "testing" "github.com/stretchr/testify/require" )

func TestDummy(t *testing.T) { c := require.New(t) result := "valor" c.Equal("valor", result) }

Las funciones de prueba en Go siempre empiezan con Test y reciben *testing.T. El objeto c que devuelve require.New(t) lleva el contexto de las aserciones [02:45].

¿Por qué usar require en lugar de assert?

require corta la ejecución del test ante el primer fallo, mientras que assert sigue evaluando. Para pruebas críticas donde un fallo invalida los siguientes pasos, require es más limpio.

¿Cómo estructurar el workflow YAML de GitHub Actions?

Los workflows viven en una ruta específica que GitHub reconoce automáticamente: .github/workflows/ en la raíz del repositorio [04:10]. Dentro creas un archivo .yaml con el nombre que prefieras, por ejemplo validate-test.yaml.

Un workflow tiene tres bloques obligatorios:

1. name: identifica el workflow.
2. on: define el evento que lo dispara, como push en ciertas ramas.
3. jobs: lista los trabajos a ejecutar, cada uno con su sistema operativo y pasos.

¿Qué es un job en GitHub Actions? Es un conjunto de pasos que se ejecutan en una misma máquina virtual. Puedes tener varios jobs en paralelo o encadenados.

¿Qué pasos debe incluir un pipeline de pruebas en Go?

El workflow replica lo que harías a mano en la terminal. Cada paso lleva un name descriptivo y un run o uses con la acción concreta [06:20]:

• Checkout code con actions/checkout@v4 para traer el código de la rama.
• Setup Go con actions/setup-go y la versión 1.18 para preparar el entorno.
• Install dependencies ejecutando go mod vendor dentro del working-directory del proyecto.
• Check unit test corriendo go test ./... para entrar recursivamente a todos los folders.

El patrón ./... es clave: evita modificar el pipeline cada vez que agregas pruebas en nuevos paquetes, porque Go las detecta automáticamente.

¿Cómo queda el archivo YAML completo?

La indentación en YAML es estricta: steps va al mismo nivel que runs-on, y cada paso empieza con un guion [09:50]. Una versión funcional luce así:

yaml name: test-workflow on: push: branches: - '*' jobs: code_validation: runs-on: ubuntu-22.04 steps: - name: Checkout code uses: actions/checkout@v4 - name: Setup Go uses: actions/setup-go@v4 with: go-version: '1.18' - name: Install dependencies working-directory: githubtracker run: go mod vendor - name: Check unit test working-directory: githubtracker run: go test ./... continue-on-error: false

La propiedad continue-on-error: false asegura que si las pruebas fallan, el workflow se marca como fallido. Es el comportamiento esperado en CI: si los tests no pasan, el pipeline no debe seguir.

¿Por qué especificar working-directory?

GitHub Actions ejecuta los comandos desde la raíz del repo por defecto. Si tu código Go vive en una subcarpeta como githubtracker, necesitas indicarle dónde correr go mod vendor y go test, o no encontrará el go.mod.

Una vez que haces push del archivo YAML al repo, GitHub detecta el workflow y lo dispara en cada push siguiente. Si quieres extenderlo a otros lenguajes o eventos, la documentación oficial tiene templates listos para Node, Python, Java y más. ¿Ya tienes un proyecto donde aplicarlo? Cuéntame en los comentarios qué pipeline configuraste primero.