infrastructure-testing

Infrastructure Testing

Infrastructure changes fail differently than application code — a syntactically valid Terraform plan can still delete a production database, and a Kubernetes manifest that passes schema validation can still deploy a container that can't reach anything it needs. "It applied without error" is not evidence of correctness; it's evidence the tool understood the syntax.

Most infrastructure testing gaps come from treating plan output as sufficient review, when a plan only tells you what will change, never whether that change is safe. Test infrastructure changes against the same rigor as application code — fast local checks first, real environments before production, no exceptions for "it's just config."

1. Build a testing pyramid sized for infrastructure

Application testing pyramids assume unit tests are cheap and environment tests are expensive; for infrastructure the same shape holds but the layers look different — a fast static check catches most mistakes, and a real environment is reserved for what nothing else can validate.

Layer	What it catches	Speed
Lint / format	Syntax, style, drift from conventions	Seconds
Validate / plan	Type errors, what would actually change	Seconds–minutes
Policy check	Violations of security or cost rules	Seconds
Unit test (module)	A module produces correct output for given inputs	Seconds–minutes
Integration test	Real resources actually work together	Minutes–hours

• Push failures as far left as possible — a mistake caught by a linter costs nothing; the same mistake caught by a failed production apply costs an incident.
• Reserve the expensive layers for what only they can catch — real network reachability, real IAM behavior, real cross-resource interaction.

Done when: every change passes lint, validate, and policy checks before it reaches a step that provisions anything real.

2. Never trust a plan you haven't diffed against intent