Tu infraestructura es código (Capítulo 9), y como todo código, puede tener errores. En este capítulo aprenderás a probar tu infraestructura para detectar problemas antes de que lleguen a producción. Empezamos por las comprobaciones más básicas y baratas: fmt y validate, ejecutadas automáticamente en CI. Son la primera línea de defensa de la calidad.

Un error en tu código Terraform puede provocar desde un fallo tonto (una llave mal cerrada) hasta un desastre serio (un Security Group que deja tu base de datos abierta a internet). Igual que pruebas el código de una aplicación antes de lanzarlo, debes probar tu infraestructura. La buena noticia es que hay varios niveles de pruebas, de las más simples a las más completas:

Empezamos por los dos primeros, que son los más fáciles y los que siempre deberías tener.

Antes de seguir, un concepto clave: CI (Continuous Integration, Integración Continua). Es un sistema automático que, cada vez que alguien propone un cambio de código (un Pull Request, subcapítulo 12.5), ejecuta una serie de comprobaciones automáticamente. Si alguna falla, avisa y bloquea el cambio hasta que se arregle.

Analogía: el CI es como un control de calidad automático en una fábrica. Cada producto (cambio de código) pasa por una cinta donde unas máquinas lo inspeccionan. Si algo no cumple los estándares, se aparta antes de salir al mercado. Nadie tiene que revisar a mano cada pieza: el sistema lo hace solo, sin cansarse ni olvidarse.

Veremos el CI a fondo en el Capítulo 22; por ahora, quédate con que es donde se ejecutan automáticamente estas pruebas.

Recuerda fmt del subcapítulo 11.4: formatea el código Terraform con un estilo uniforme (indentación, alineación). En CI se usa en modo comprobación, para verificar que el código está bien formateado, sin cambiarlo:

¿Por qué comprobar el formato en CI? Para que todo el código del equipo tenga el mismo estilo, siempre. Sin esto, cada persona formatearía a su manera y el código sería un caos de estilos mezclados. Con la comprobación en CI, nadie puede fusionar código mal formateado: es un estándar automático que elimina discusiones de estilo.

Recuerda validate del subcapítulo 11.4: comprueba que el código es válido (sin errores de sintaxis ni referencias rotas), sin conectarse a AWS ni crear nada. En CI se ejecuta así:

¿Por qué validar en CI? Para cazar errores básicos al instante, antes de que nadie intente aplicar el código. Si alguien escribe mal el nombre de un argumento o referencia un recurso que no existe, validate lo detecta en segundos, y el CI bloquea el cambio. Es mucho mejor descubrirlo aquí que cuando intentas desplegar.

Juntando ambos, un pipeline de CI básico para Terraform empieza así:

Si fmt o validate fallan, el proceso se detiene ahí: no tiene sentido seguir con código mal formateado o inválido. Solo si pasan estas comprobaciones básicas se continúa con las demás.

fmt y validate son la base del testing de infraestructura por dos razones:

• Son baratísimos: se ejecutan en segundos, no necesitan credenciales de AWS ni crean nada. No cuesta nada tenerlos.
• Cazan los errores más comunes: muchos fallos del día a día son de formato o de sintaxis, y estos dos comandos los eliminan de raíz.

Consejo práctico: aunque no tengas todavía un pipeline de CI completo, configura al menos fmt -check y validate desde el primer día. Es el mínimo esfuerzo con el mayor retorno en calidad. Las pruebas más avanzadas (seguridad, integración) las añades después.

• La infraestructura es código, y como tal puede tener errores; hay que probarla antes de que llegue a producción, en niveles de menos a más completos: fmt → validate → seguridad → integración.
• El CI (Integración Continua) es un sistema automático que ejecuta comprobaciones cada vez que se propone un cambio (un PR) y bloquea los que fallan. Como un control de calidad automático en una fábrica.
• terraform fmt -check verifica que el código tenga un formato consistente, garantizando un estilo uniforme en todo el equipo.
• terraform validate comprueba que el código sea válido (sintaxis y referencias), cazando errores básicos al instante, sin tocar AWS.
• Son la base del testing: baratísimos (segundos, sin credenciales) y cazan los errores más comunes. Configúralos desde el primer día.

En el siguiente subcapítulo subiremos un nivel: el análisis de seguridad estático con Checkov y tfsec, que detectan configuraciones peligrosas antes de desplegarlas.