Why Infrastructure Needs Tests
Think of infrastructure code the way you'd think of a recipe. A recipe that lists the wrong oven temperature won't fail until you actually try to bake something — and by then, you've wasted time, ingredients, and possibly ruined dinner. Infrastructure code is the same: a misconfigured security group or a wrong subnet ID won't fail until you deploy, and by then you may have exposed a database to the internet or broken production.
For years, software developers have used automated testing to catch bugs before they reach users. Infrastructure engineers, however, often relied on "deploy and see what breaks" — manually checking things after the fact. As infrastructure becomes defined by code (Terraform, Pulumi, CloudFormation), we must apply the same rigorous testing discipline. A bug in your infrastructure code can take down your entire application, corrupt data, or open massive security holes — often silently.
The goal of infrastructure testing is to shift the discovery of problems as far left as possible — meaning: catch them earlier in the development process, before they reach production. The earlier you catch a bug, the cheaper it is to fix.
The Infrastructure Testing Pyramid
Just like application testing, infrastructure testing has different layers. Each layer trades speed for realism:
- Static Analysis: Checking the code itself for syntax errors, deprecated patterns, and bad practices — without running it. Runs in seconds. No cloud credentials needed.
- Plan Analysis: Checking the proposed changes (
terraform plan) against security and compliance policies. Catches what the code will do before it does it. - Integration Testing: Actually deploying resources to a real cloud environment, verifying they work correctly, and then destroying them. Slowest, but the only way to prove your infrastructure actually functions end-to-end.
The pyramid shape is intentional: you should have many static checks, fewer plan checks, and a targeted set of integration tests. Running integration tests on every single commit is expensive and slow — but running them nightly or on pull requests to main is a reasonable trade-off.
Interviewers often ask: "How do you test Terraform code?" A weak answer is "I run terraform plan and review it." A strong answer walks through the pyramid: static analysis with tflint, policy enforcement with OPA against the plan JSON, and integration tests with Terratest for critical modules. Mention that integration tests are expensive so you run them selectively — not on every commit.