Hemos visto comprobaciones que analizan el código sin ejecutarlo (fmt, validate, Checkov, tfsec). Son rápidas y útiles, pero tienen un límite: no comprueban que tu infraestructura funcione de verdad una vez creada. Para eso existen los tests de integración, y la herramienta más conocida en el mundo Terraform es Terratest. En este subcapítulo entenderás qué aportan y cómo funcionan a grandes rasgos.

Las herramientas de los subcapítulos anteriores leen tu código, pero no crean nada. Pueden decirte «este código parece correcto y seguro», pero no pueden responder a preguntas como:

• ¿La instancia EC2 arranca de verdad y responde?
• ¿El servidor web devuelve la página esperada?
• ¿El balanceador reparte el tráfico correctamente?
• ¿Los recursos se conectan entre sí como deberían?

Para responder a esto, no basta con leer el código: hay que crear la infraestructura de verdad y probarla. Eso es un test de integración.

Un test de integración sigue este ciclo: crea la infraestructura real (en un entorno de pruebas), verifica que funciona como esperas, y luego la destruye para no dejar nada ni seguir pagando.

Analogía: el análisis estático es como revisar los planos de un coche; el test de integración es como construir un prototipo y conducirlo en un circuito de pruebas para ver si de verdad arranca, frena y gira. Después del test, se desmonta el prototipo. Es más costoso que mirar los planos, pero te da una certeza que el papel no puede dar.

Terratest es una librería de Go (creada por Gruntwork) para escribir tests de integración de infraestructura. Con ella, escribes un pequeño programa en el lenguaje Go que automatiza todo el ciclo: aplica tu Terraform, hace comprobaciones y destruye la infraestructura al final.

Un test con Terratest, a grandes rasgos, hace algo como esto (no necesitas dominar Go para entender la idea):

Fíjate en el patrón:

• Apply: crea la infraestructura (usa tu código Terraform real).
• Verificar: lee los outputs (recuerda el subcapítulo 12.4) y comprueba cosas reales, como que el servidor web responde.
• Destroy (con defer): se asegura de limpiar siempre, incluso si el test falla. Esto es crucial para no dejar recursos costosos olvidados.

Terratest te permite comprobar que la infraestructura funciona de verdad:

• Que una web responde con el código y contenido esperados.
• Que un servidor es accesible por SSH o por un puerto.
• Que una base de datos acepta conexiones.
• Que los outputs de Terraform tienen los valores correctos.
• Que un módulo (Capítulo 18) crea exactamente los recursos que promete.

Es especialmente útil para probar módulos reutilizables: antes de publicar una nueva versión de tu módulo (subcapítulo 18.4), un test de integración confirma que sigue funcionando.

Los tests de integración son los más completos, pero también los más costosos, y conviene ser consciente de ello:

Por eso no se ejecutan en cada cambio trivial: como crean recursos reales (lleva minutos y cuesta dinero), los tests de integración se suelen reservar para cambios importantes, para validar módulos antes de publicarlos, o se ejecutan periódicamente (por ejemplo, cada noche), en vez de en cada pequeño commit.

No de entrada. La pirámide de testing tiene sentido por orden de coste/beneficio:

Empieza por la base (fmt, validate), añade seguridad (Checkov/tfsec), y reserva los tests de integración para cuando tu infraestructura sea crítica o publiques módulos reutilizables que muchos van a usar. No necesitas Terratest desde el primer día, pero conviene saber que existe y qué problema resuelve.

• El análisis estático (fmt, validate, Checkov) lee el código pero no comprueba que la infraestructura funcione de verdad; para eso están los tests de integración.
• Un test de integración sigue el ciclo crear → verificar → destruir: monta la infra real en una cuenta de pruebas, comprueba que funciona y la elimina. Como construir y conducir un prototipo, no solo mirar los planos.
• Terratest es una librería de Go que automatiza ese ciclo (apply → comprobaciones → destroy), asegurándose de limpiar siempre (con defer destroy), incluso si el test falla.
• Permite verificar cosas reales: que una web responde, que un servidor es accesible, que los outputs son correctos, que un módulo crea lo que promete (ideal para validar módulos).
• Son los tests más completos pero también los más costosos (crean recursos reales, llevan minutos, cuestan dinero, requieren Go); se reservan para lo importante, no para cada cambio trivial. Empieza por la base de la pirámide.

En el último subcapítulo del capítulo veremos una técnica para asegurar que los módulos encajan bien entre sí: el contract testing entre módulos.