Mocks en Go para aislar la base de datos

Aprende a configurar GitHub Actions para validar tu código y a crear pruebas unitarias con mocks en Go, desde el primer commit hasta ver el check verde. Con un flujo claro de push, revisión del workflow y un unit test que aísla la base de datos, podrás asegurar la lógica de negocio sin fricción.

¿Cómo configurar GitHub Actions y entender el workflow?

Configurar el workflow de validación permite correr pruebas automáticamente con cada push. Aquí se ilustra cómo leer errores, corregir la sintaxis y verificar que la tubería ejecuta los pasos esperados.

¿Qué indica el error en GitHub Actions?

• Mensaje clave: Code validation: Unable to resolve action 'unableToFindVersion4'.
• Causa: error de sintaxis al referenciar checkout (se ajusta a B4 según el archivo yml mencionado).
• Acción: corregir el workflow, hacer commit y push de la fix.
• Resultado: aparece el chulito verde en la rama main y se confirma que el workflow corrió.

¿Cómo validar el flujo de build y tests?

• Pasos visibles en Actions: setup job, checkout code, setup go, instalación de dependencias, chequeo de pruebas.
• Estado inicial: no se encontraron pruebas en los directorios esperados, pero el flujo quedó listo para ejecutarlas cuando existan.
• Beneficio: feedback rápido y centralizado en GitHub con cada cambio.

¿Cómo crear un unit test con mocks en Go?

El enfoque se centra en aislar la base de datos usando mocks y en probar solo la lógica del método insertGitHubWebhook.

¿Qué datos se preparan para el test?

• Estructuras: webhook con repository y head commit extraídos de ejemplos previos.
• Cuerpo: conversión a JSON con json.Marshal para obtener el body.
• Tiempo: created time con time.Now al iniciar la prueba.
• Repositorio simulado: inicialización de un objeto mock reutilizable en la prueba.

¿Cómo se define la entidad esperada?

• Entidad commit.Entity con estos campos:
• repo name tomado de webhook.repository.full_name.
• commit ID desde head commit id.
• commit message desde el head commit.
• author username y email del head commit author.
• payload convertido de arreglo de bytes a string.
• created at y updated at iguales a created time.
• Objetivo: especificar con precisión lo que el método debe producir.

¿Cómo se configuran expectativas y asserts?

• Método del repositorio: insert con argumentos esperados, incluyendo context.Background y la entidad correcta.
• Respuesta simulada: retorno nil para el caso exitoso. Se podría definir un error para probar fallas.
• Ejecución: llamar a insertGitHubWebhook con context, mock, webhook, body y created time.
• Verificación: assert de no error y verificación de expectativas del mock para confirmar que se invocó con los valores definidos.
• Nota importante: se aclara que el método insert no recibe un webhook, sino un commit.

¿Cómo comprobar localmente y en GitHub Actions?

Validar en ambos entornos refuerza la confianza y cierra el ciclo CI básico.

¿Qué resultados se observan al correr tests?

• Local: las pruebas pasan, confirmando que la lógica funciona con el mock.
• Remoto: tras el push, el indicador amarillo muestra ejecución en curso y luego pasa a completado.
• En Actions: se ve la ejecución de unit test para el módulo GitHub Tracker y se verifica el check verde.

Palabras clave que refuerzan las habilidades practicadas: - GitHub Actions, workflow, job, checkout, setup go, archivo yml. - Commit, push, rama main, details en Actions. - Mock, repository, insert, insertGitHubWebhook, webhook, JSON, context.Background, assert, nil, error. - commit.Entity, repo name, head commit id, commit message, author username, author email, payload, created at, updated at.

¿Te gustaría comentar cómo modelarías pruebas de fallo con mocks o qué otros eventos de webhook validarías?