Test-Driven Infrastructure: Applying TDD to Infrastructure as Code

How to apply Test-Driven Development principles to cloud infrastructure with Terraform, Kubernetes, and GitOps by testing rules before deployment.

Test-Driven Infrastructure  

Applying TDD to Infrastructure as Code  

Test-Driven Development (TDD) is now well established on the application side.
However, when it comes to infrastructure, many still consider TDD unnecessary, too complex, or unsuitable.

That is a mistake.

TDD applied to infrastructure already exists, often without being named as such. When properly understood, it becomes a major lever for securing, structuring, and evolving a cloud platform.

This article explains what TDD really means in infrastructure, how to apply it concretely, and why it becomes essential as systems grow.

Reminder: what is TDD?  

TDD is based on a simple cycle:

1. Red – write a failing test
2. Green – write the minimum needed to make the test pass
3. Refactor – improve the solution without changing its behavior

The goal is not the test itself, but the fact that the test comes before the design.

That is precisely what makes TDD particularly relevant for infrastructure.

Why infrastructure is a special case  

Infrastructure has three characteristics that make it harder to test:

• it is declarative (Terraform, CloudFormation, Kubernetes manifests),
• it depends on real external systems (cloud providers, clusters),
• it is often validated after deployment, which is too late.

Historically, infrastructure is considered “tested” when:

• terraform apply succeeds without errors,
• resources appear in the console,
• the application works in production.

These are not TDD tests.
They are observations made after the fact.

What it really means to “test” infrastructure  

In infrastructure TDD, a test does not verify that:

“the resource exists”

It verifies that:

“the generated infrastructure respects a set of explicit rules.”

So we are not testing objects, but invariants.

Examples of invariants:

• storage is always encrypted
• an exposed service is always protected by TLS
• a pod defines requests and limits
• a public resource is explicitly declared as such

These rules must be validated before any deployment.

Testing before deployment: the core of infrastructure TDD  

Infrastructure TDD runs before actual execution.

Terraform: test the plan, not the cloud  

With Terraform, the main test target is the plan.

We do not test AWS.
We test what Terraform is going to ask AWS to do.

Examples of testable rules:

• an S3 bucket must never be public
• versioning is mandatory
• default encryption is enabled
• critical resources cannot be accidentally destroyed

These tests can be implemented through:

• unit tests against the plan output
• policies (OPA, Sentinel)
• frameworks like Terratest in non-destructive mode

Real deployment then becomes an implementation detail, not a moment of discovery.

Kubernetes: test the manifests, not the cluster  

The reasoning is the same for Kubernetes.

We test the generated manifests, not the behavior of the cluster.

Examples of rules:

• no image may use the latest tag
• requests and limits are mandatory
• standard labels are required
• forbidden ports or capabilities are rejected
• namespaces must be clearly separated

These tests run:

• before kubectl apply
• in CI
• before any merge into the main branch

Test rules, not values  

A core TDD principle:

❌ Bad test

“the subnet must be named prod-subnet-1”

✅ Good test

“any subnet exposed to the Internet must be explicitly public”

Values change.
Structuring rules should remain stable.

A good infrastructure test expresses a business, security, or platform intention, never a cosmetic detail.

Infrastructure TDD as a design tool  

As with application TDD, tests reveal the quality of the design.

When you start writing infrastructure tests:

• oversized modules become hard to test
• implicit dependencies become visible
• vague abstractions become painful

The rule remains the same:

if it is hard to test, it is probably badly designed

Infrastructure TDD naturally pushes toward:

• smaller modules
• clearer responsibilities
• explicit interfaces
• invariants documented by the tests themselves

Red / Green / Refactor applied to infrastructure  

The TDD cycle truly exists in infrastructure, but at a more abstract level.

🔴 Red  

Need:

“expose a secure HTTP service”

Tests:

• TLS is mandatory
• no direct public IP
• strict network rules
• logging enabled

🟢 Green  

Minimal implementation:

• load balancer
• certificates
• required network rules

🔁 Refactor  

• factorization into a module
• renaming
• public / private separation
• readability improvements

The tests remain unchanged.
They describe the rule, not the solution.

Infrastructure TDD ≠ integration tests  

A common confusion is to mix up infrastructure TDD and integration tests.

Infrastructure TDD removes a large share of errors before execution even begins.

Why infrastructure TDD is still not widely adopted  

The reasons are often organizational:

• delivery pressure
• excessive trust in terraform plan
• a “scripted clickops” culture
• lack of training and standards

And yet, as soon as you work with:

• multiple cloud accounts
• multiple teams
• GitOps
• strong security constraints

Not testing infrastructure becomes a systemic risk.

Ecosystems that are favorable to infrastructure TDD  

Infrastructure TDD integrates naturally with:

• GitOps
• reusable platform modules
• policy as code (OPA, Sentinel)
• strict CI pipelines
• internal platforms and golden paths

Conclusion  

TDD in infrastructure is not an extra layer of tests.
It is a change in mindset.

We no longer deploy to see whether it works.
We prove that the infrastructure respects the rules before it even exists.

At scale, this is not a luxury.
It is a condition for survival.