Testing and Validation

The day untested Terraform destroyed production taught me that infrastructure needs tests just like code

---

Table of Contents

1. Introduction: The Untested Deployment

2. Why Test Infrastructure Code?

3. Levels of Testing

4. Input Validation

5. terraform validate

6. terraform fmt - Code Formatting

7. terraform plan - The First Test

8. Static Analysis and Linting

9. Unit Testing with Terratest

10. Integration Testing

11. Contract Testing

12. Policy as Code

13. Real-World Example: Comprehensive Testing Pipeline

14. CI/CD for Terraform

15. Test-Driven Development (TDD) for Infrastructure

16. Common Testing Patterns

17. Testing Best Practices

18. What I Learned About Testing Infrastructure

19. Next Steps

---

Introduction: The Untested Deployment

It was a Wednesday morning. I had just merged a "simple" change to our Terraform configuration—updating a variable validation rule. The code review was quick. The tests? Well... there weren't any.

"It's just validation," I thought. "What could go wrong?"

I deployed to production.

Everything broke.

Turns out, my validation rule was stricter than I intended. It rejected ALL environment names, including "production". The deployment pipeline failed halfway through, leaving infrastructure in an inconsistent state. Services couldn't start. Alerts flooded in.

My manager's question haunted me: "Did you test this?"

I hadn't.

That incident sparked a journey into infrastructure testing. I learned that Terraform code needs testing just as much as application code—maybe more, because infrastructure failures affect everything.

I discovered:

• Validation catches syntax errors before apply

• Linting enforces best practices

• Unit tests verify module behavior

• Integration tests ensure components work together

• Policy tests enforce security and compliance

This article is everything I learned about testing Terraform, from basic validation to comprehensive test suites that prevent production disasters.

---

Why Test Infrastructure Code?

The Cost of Infrastructure Bugs

Application bug:

• One service down

• Rollback and redeploy

• Minutes to hours of downtime

Infrastructure bug:

• Multiple services down

• Database corruption risk

• Network isolation

• Hours to days of recovery

• Potential data loss

What Testing Prevents

1. Syntax errors

resource "local_file" "config" {
  filename = "app.conf"
  content  = "data"
  # Missing closing brace - syntax error

2. Invalid configurations

variable "port" {
  type = number
}

# Passing string to number variable - validation error

3. Resource conflicts

# Two resources trying to create same file
resource "local_file" "config1" {
  filename = "app.conf"
}

resource "local_file" "config2" {
  filename = "app.conf"  # Conflict!
}

4. Security violations

# Unencrypted sensitive data
resource "local_file" "secrets" {
  filename = "secrets.txt"
  content  = "password123"  # Should be encrypted!
}

5. Compliance violations

# Production without backup
resource "database" "prod" {
  name   = "production"
  backup = false  # Policy violation!
}

Testing Benefits

---

Levels of Testing

Testing Pyramid for Infrastructure

1. Linting (Fast, many tests)

• Code formatting

• Best practices

• Security checks

2. Validation (Fast)

• Syntax validation

• Type checking

• Basic logic

3. Unit Tests (Medium speed)

• Module behavior

• Input/output contracts

• Edge cases

4. Integration Tests (Slower)

• Module interactions

• Real resources

• End-to-end workflows

5. Policy Tests (Continuous)

• Security compliance

• Cost controls

• Organizational standards

---

Input Validation

Validate inputs before Terraform even runs.

Basic Validation

variable "environment" {
  type        = string
  description = "Environment name"
  
  validation {
    condition     = contains(["dev", "staging", "production"], var.environment)
    error_message = "Environment must be dev, staging, or production."
  }
}

Test:

terraform plan -var="environment=invalid"

Error:

Error: Invalid value for variable

  on variables.tf line 1:
   1: variable "environment" {

Environment must be dev, staging, or production.

Complex Validation Rules

Port range:

variable "port" {
  type        = number
  description = "Service port"
  
  validation {
    condition     = var.port >= 1024 && var.port <= 65535
    error_message = "Port must be between 1024 and 65535."
  }
}

String format:

variable "service_name" {
  type        = string
  description = "Service name (alphanumeric, lowercase, max 32 chars)"
  
  validation {
    condition     = can(regex("^[a-z0-9]{1,32}$", var.service_name))
    error_message = "Service name must be lowercase alphanumeric, max 32 characters."
  }
}

Email address:

variable "admin_email" {
  type        = string
  description = "Administrator email address"
  
  validation {
    condition     = can(regex("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$", var.admin_email))
    error_message = "Must be a valid email address."
  }
}

IP address:

variable "ip_address" {
  type        = string
  description = "IP address"
  
  validation {
    condition     = can(cidrhost("${var.ip_address}/32", 0))
    error_message = "Must be a valid IP address."
  }
}

Multiple Validation Rules

variable "instance_config" {
  type = object({
    type     = string
    count    = number
    disk_gb  = number
  })
  
  validation {
    condition     = contains(["small", "medium", "large"], var.instance_config.type)
    error_message = "Instance type must be small, medium, or large."
  }
  
  validation {
    condition     = var.instance_config.count >= 1 && var.instance_config.count <= 10
    error_message = "Instance count must be between 1 and 10."
  }
  
  validation {
    condition     = var.instance_config.disk_gb >= 10 && var.instance_config.disk_gb <= 1000
    error_message = "Disk size must be between 10 and 1000 GB."
  }
}

Precondition and Postcondition Checks

Preconditions (Terraform 1.2+):

resource "local_file" "config" {
  filename = var.filename
  content  = var.content
  
  lifecycle {
    precondition {
      condition     = length(var.content) > 0
      error_message = "Content cannot be empty."
    }
    
    precondition {
      condition     = !strcontains(var.filename, "..")
      error_message = "Filename cannot contain '..' path traversal."
    }
  }
}

Postconditions:

resource "random_integer" "port" {
  min = 8000
  max = 9000
  
  lifecycle {
    postcondition {
      condition     = self.result >= 8000 && self.result <= 9000
      error_message = "Generated port out of expected range."
    }
  }
}

---

terraform validate

Basic syntax and configuration validation.

What It Checks

• ✅ Syntax errors

• ✅ Invalid resource types

• ✅ Invalid attribute names

• ✅ Type mismatches

• ✅ Missing required attributes

• ✅ Variable validation rules

What It Doesn't Check

• ❌ Resource conflicts

• ❌ State consistency

• ❌ Provider authentication

• ❌ Network connectivity

• ❌ Resource quotas

Usage

terraform validate

Success:

Success! The configuration is valid.

Failure:

Error: Invalid resource type

  on main.tf line 5, in resource "invalid_type" "example":
   5: resource "invalid_type" "example" {

The provider hashicorp/local does not support resource type "invalid_type".

Common Errors Caught by Validate

1. Invalid resource type:

resource "local_invalid" "test" {
  filename = "test.txt"
}

2. Missing required argument:

resource "local_file" "test" {
  # Missing required 'filename'
  content = "test"
}

3. Type mismatch:

variable "count" {
  type = number
}

resource "local_file" "test" {
  count = var.count  # OK
}

# Later...
# terraform plan -var='count="not a number"'  # Error!

4. Validation rule violation:

variable "env" {
  validation {
    condition = contains(["dev", "prod"], var.env)
    error_message = "Must be dev or prod."
  }
}

# terraform plan -var='env=invalid'  # Error!

Validate in CI/CD

#!/bin/bash
set -e

echo "Initializing Terraform..."
terraform init -backend=false

echo "Validating configuration..."
terraform validate

echo "✅ Validation passed"

---

terraform fmt - Code Formatting

Consistent code formatting.

What It Does

• Standardizes indentation

• Aligns equals signs

• Sorts arguments

• Removes trailing whitespace

• Ensures consistent style

Usage

Check formatting:

terraform fmt -check

Format files:

terraform fmt

Format recursively:

terraform fmt -recursive

Show diff:

terraform fmt -diff

Before and After

Before:

resource "local_file" "config" {
filename="app.conf"
  content=  "data"
    file_permission="0644"
}

After:

terraform fmt

resource "local_file" "config" {
  filename        = "app.conf"
  content         = "data"
  file_permission = "0644"
}

In CI/CD

#!/bin/bash
set -e

echo "Checking Terraform formatting..."
if ! terraform fmt -check -recursive; then
  echo "❌ Formatting errors found. Run 'terraform fmt -recursive'"
  exit 1
fi

echo "✅ Formatting is correct"

Pre-commit Hook

.git/hooks/pre-commit:

#!/bin/bash

# Format all Terraform files
terraform fmt -recursive

# Add formatted files to commit
git add *.tf

Make executable:

chmod +x .git/hooks/pre-commit

---

terraform plan - The First Test

terraform plan is your first integration test.

What Plan Tests

• ✅ Configuration validity

• ✅ Provider connectivity

• ✅ Resource conflicts

• ✅ State consistency

• ✅ Dependency resolution

• ✅ Change impact

Safe Plan Testing

# Read-only plan (no state modification)
terraform plan

# Save plan for review
terraform plan -out=tfplan

# Detailed output
terraform plan -json > plan.json

# Specific target
terraform plan -target=local_file.config

Plan in CI/CD

#!/bin/bash
set -e

terraform init
terraform plan -out=tfplan

# Analyze plan output
terraform show -json tfplan > plan.json

# Check for destructive changes
if grep -q '"delete"' plan.json; then
  echo "⚠️  Plan contains destructive changes!"
  exit 1
fi

echo "✅ Plan looks safe"

Plan Assertions

Check plan output for expected changes:

#!/bin/bash

# Run plan and capture output
terraform plan -no-color > plan.txt

# Check expected resource creation
if ! grep -q "local_file.config will be created" plan.txt; then
  echo "❌ Expected resource not in plan"
  exit 1
fi

# Check no unwanted deletions
if grep -q "will be destroyed" plan.txt; then
  echo "❌ Unexpected resource deletion"
  exit 1
fi

echo "✅ Plan matches expectations"

---

Static Analysis and Linting

Enforce best practices with linting tools.

TFLint

Install:

# macOS
brew install tflint

# Linux
curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash

Usage:

tflint --init
tflint

Configuration (.tflint.hcl):

plugin "terraform" {
  enabled = true
  preset  = "recommended"
}

rule "terraform_naming_convention" {
  enabled = true
  
  format = "snake_case"
}

rule "terraform_documented_variables" {
  enabled = true
}

rule "terraform_unused_declarations" {
  enabled = true
}

Checkov

Install:

pip install checkov

Usage:

checkov -d .

What it checks:

• Security best practices

• Compliance standards

• Common misconfigurations

Example output:

Check: CKV_LOCAL_1: "Ensure file permissions are set appropriately"
	FAILED for resource: local_file.config
	File: /main.tf:1-5

Check: CKV_LOCAL_2: "Ensure sensitive data is not exposed"
	PASSED for resource: local_file.secrets

tfsec

Install:

brew install tfsec

Usage:

tfsec .

What it checks:

• Security vulnerabilities

• Encryption settings

• Access controls

• Network exposure

Terrascan

Install:

brew install terrascan

Usage:

terrascan scan

Compliance frameworks:

• CIS Benchmarks

• NIST

• HIPAA

• GDPR

---

Unit Testing with Terratest

Test modules in isolation.

What is Terratest?

Terratest is a Go library for testing infrastructure code.

Install Go

# macOS
brew install go

# Verify
go version

Project Structure

module-under-test/
├── main.tf
├── variables.tf
├── outputs.tf
└── test/
    ├── go.mod
    ├── go.sum
    └── module_test.go

Simple Terratest Example

Module (main.tf):

variable "filename" {
  type = string
}

variable "content" {
  type = string
}

resource "local_file" "test" {
  filename = var.filename
  content  = var.content
}

output "file_id" {
  value = local_file.test.id
}

output "content" {
  value = local_file.test.content
}

Test (test/module_test.go):

package test

import (
	"testing"
	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/stretchr/testify/assert"
)

func TestLocalFileModule(t *testing.T) {
	// Arrange
	terraformOptions := &terraform.Options{
		TerraformDir: "../",
		Vars: map[string]interface{}{
			"filename": "test.txt",
			"content":  "Hello, Terratest!",
		},
	}

	// Cleanup
	defer terraform.Destroy(t, terraformOptions)

	// Act
	terraform.InitAndApply(t, terraformOptions)

	// Assert
	fileID := terraform.Output(t, terraformOptions, "file_id")
	content := terraform.Output(t, terraformOptions, "content")

	assert.NotEmpty(t, fileID)
	assert.Equal(t, "Hello, Terratest!", content)
}

Initialize:

cd test
go mod init test
go mod tidy

Run test:

go test -v -timeout 30m

Complex Test Example

package test

import (
	"testing"
	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/stretchr/testify/assert"
)

func TestServiceModule(t *testing.T) {
	t.Parallel()

	tests := []struct {
		name        string
		serviceName string
		port        int
		expectError bool
	}{
		{
			name:        "Valid web service",
			serviceName: "web",
			port:        8080,
			expectError: false,
		},
		{
			name:        "Valid API service",
			serviceName: "api",
			port:        8081,
			expectError: false,
		},
		{
			name:        "Invalid port (too low)",
			serviceName: "invalid",
			port:        100,
			expectError: true,
		},
	}

	for _, tt := range tests {
		tt := tt // Capture range variable
		t.Run(tt.name, func(t *testing.T) {
			t.Parallel()

			terraformOptions := &terraform.Options{
				TerraformDir: "../",
				Vars: map[string]interface{}{
					"service_name": tt.serviceName,
					"port":         tt.port,
				},
			}

			defer terraform.Destroy(t, terraformOptions)

			if tt.expectError {
				_, err := terraform.InitAndApplyE(t, terraformOptions)
				assert.Error(t, err)
			} else {
				terraform.InitAndApply(t, terraformOptions)
				
				serviceName := terraform.Output(t, terraformOptions, "service_name")
				port := terraform.Output(t, terraformOptions, "port")
				
				assert.Equal(t, tt.serviceName, serviceName)
				assert.NotEmpty(t, port)
			}
		})
	}
}

---

Integration Testing

Test multiple modules working together.

Integration Test Structure

integration-test/
├── fixtures/
│   └── complete/
│       ├── main.tf         # Uses multiple modules
│       ├── variables.tf
│       └── outputs.tf
└── test/
    ├── go.mod
    └── integration_test.go

Integration Test Example

fixtures/complete/main.tf:

module "database" {
  source = "../../modules/database"
  
  environment = var.environment
  db_name     = "testdb"
}

module "application" {
  source = "../../modules/application"
  
  environment = var.environment
  service_name = "testsvc"
  db_host      = module.database.host
  db_port      = module.database.port
}

output "app_endpoint" {
  value = module.application.endpoint
}

output "db_connection" {
  value = module.database.connection_string
}

test/integration_test.go:

package test

import (
	"testing"
	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/stretchr/testify/assert"
)

func TestCompleteIntegration(t *testing.T) {
	t.Parallel()

	terraformOptions := &terraform.Options{
		TerraformDir: "../fixtures/complete",
		Vars: map[string]interface{}{
			"environment": "test",
		},
	}

	defer terraform.Destroy(t, terraformOptions)

	terraform.InitAndApply(t, terraformOptions)

	// Test database module outputs
	dbConnection := terraform.Output(t, terraformOptions, "db_connection")
	assert.Contains(t, dbConnection, "testdb")

	// Test application module outputs
	appEndpoint := terraform.Output(t, terraformOptions, "app_endpoint")
	assert.Contains(t, appEndpoint, "http://")
}

---

Contract Testing

Test module interfaces remain stable.

What is Contract Testing?

Ensures modules don't break their public interface (inputs/outputs).

Contract Test Example

package test

import (
	"testing"
	"github.com/gruntwork-io/terratest/modules/terraform"
	"github.com/stretchr/testify/assert"
)

func TestModuleContract(t *testing.T) {
	t.Parallel()

	terraformOptions := &terraform.Options{
		TerraformDir: "../",
	}

	// Initialize to load module metadata
	terraform.Init(t, terraformOptions)

	// Test required inputs exist
	requiredInputs := []string{"service_name", "environment", "port"}
	for _, input := range requiredInputs {
		// Verify input is documented
		assert.NotEmpty(t, terraform.GetVariableDescription(t, terraformOptions, input))
	}

	// Test expected outputs exist
	terraform.InitAndApply(t, terraformOptions)
	defer terraform.Destroy(t, terraformOptions)

	expectedOutputs := []string{"service_name", "endpoint", "config_file"}
	for _, output := range expectedOutputs {
		value := terraform.Output(t, terraformOptions, output)
		assert.NotEmpty(t, value, "Output %s should not be empty", output)
	}
}

---

Policy as Code

Enforce organizational policies automatically.

Open Policy Agent (OPA)

Install:

brew install opa

Policy (policy.rego):

package terraform

# Deny resources without required tags
deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "local_file"
  not resource.change.after.tags.Environment
  msg := sprintf("Resource %s missing required tag: Environment", [resource.address])
}

# Deny file permissions more permissive than 0644
deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "local_file"
  permissions := resource.change.after.file_permission
  permissions > "0644"
  msg := sprintf("File %s has overly permissive permissions: %s", [resource.address, permissions])
}

# Warn about production changes
warn[msg] {
  resource := input.resource_changes[_]
  contains(resource.address, "production")
  resource.change.actions[_] == "delete"
  msg := sprintf("⚠️  WARNING: Deleting production resource: %s", [resource.address])
}

Test policy:

# Generate plan
terraform plan -out=tfplan
terraform show -json tfplan > plan.json

# Test against policy
opa eval -i plan.json -d policy.rego "data.terraform.deny"

Sentinel (Terraform Cloud)

Policy (sentinel.hcl):

policy "enforce-mandatory-tags" {
  enforcement_level = "hard-mandatory"
}

policy "restrict-resource-types" {
  enforcement_level = "soft-mandatory"
}

policy "limit-cost" {
  enforcement_level = "advisory"
}

Policy rule (enforce-mandatory-tags.sentinel):

import "tfplan/v2" as tfplan

mandatory_tags = ["Environment", "Owner", "Project"]

violators = filter tfplan.resource_changes as _, rc {
  rc.type == "local_file" and
  any mandatory_tags as tag {
    rc.change.after.tags[tag] else null is null
  }
}

main = rule {
  length(violators) == 0
}

---

Real-World Example: Comprehensive Testing Pipeline

Complete testing setup for production.

Project Structure

terraform-project/
├── modules/
│   ├── service/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── test/
│   │       ├── go.mod
│   │       └── service_test.go
│   └── database/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       └── test/
│           ├── go.mod
│           └── database_test.go
├── environments/
│   ├── dev/
│   ├── staging/
│   └── production/
├── policies/
│   ├── security.rego
│   └── compliance.rego
├── scripts/
│   ├── validate.sh
│   ├── test.sh
│   └── lint.sh
├── .tflint.hcl
├── .github/
│   └── workflows/
│       └── terraform-ci.yml
└── Makefile

Validation Script

scripts/validate.sh:

#!/bin/bash
set -e

echo "🔍 Running Terraform validation..."

# Format check
echo "Checking formatting..."
terraform fmt -check -recursive || {
  echo "❌ Formatting errors found. Run 'terraform fmt -recursive'"
  exit 1
}

# Validate each environment
for env in dev staging production; do
  echo "Validating $env environment..."
  cd "environments/$env"
  terraform init -backend=false
  terraform validate
  cd ../..
done

echo "✅ Validation passed"

Linting Script

scripts/lint.sh:

#!/bin/bash
set -e

echo "🔍 Running linters..."

# TFLint
echo "Running TFLint..."
tflint --init
tflint --recursive

# tfsec
echo "Running tfsec..."
tfsec .

# Checkov
echo "Running Checkov..."
checkov -d . --quiet

echo "✅ Linting passed"

Test Script

scripts/test.sh:

#!/bin/bash
set -e

echo "🧪 Running tests..."

# Unit tests
echo "Running unit tests..."
for module in modules/*/test; do
  if [ -f "$module/go.mod" ]; then
    echo "Testing $(dirname $module)..."
    cd "$module"
    go test -v -timeout 30m
    cd -
  fi
done

echo "✅ Tests passed"

Makefile

.PHONY: help init validate lint test all clean

help:
	@echo "Available targets:"
	@echo "  init     - Initialize Terraform"
	@echo "  validate - Run validation checks"
	@echo "  lint     - Run linting tools"
	@echo "  test     - Run tests"
	@echo "  all      - Run all checks"
	@echo "  clean    - Clean up generated files"

init:
	@echo "Initializing Terraform..."
	@for env in dev staging production; do \
		cd environments/$$env && terraform init && cd ../..; \
	done

validate:
	@./scripts/validate.sh

lint:
	@./scripts/lint.sh

test:
	@./scripts/test.sh

all: validate lint test
	@echo "✅ All checks passed!"

clean:
	@find . -type d -name ".terraform" -exec rm -rf {} +
	@find . -type f -name "*.tfstate*" -delete
	@find . -type f -name "tfplan" -delete

GitHub Actions Workflow

.github/workflows/terraform-ci.yml:

name: Terraform CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.6.0
      
      - name: Terraform Format
        run: terraform fmt -check -recursive
      
      - name: Terraform Init
        run: |
          for env in dev staging production; do
            cd environments/$env
            terraform init -backend=false
            cd ../..
          done
      
      - name: Terraform Validate
        run: |
          for env in dev staging production; do
            cd environments/$env
            terraform validate
            cd ../..
          done

  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup TFLint
        uses: terraform-linters/setup-tflint@v3
      
      - name: Run TFLint
        run: |
          tflint --init
          tflint --recursive
      
      - name: Run tfsec
        uses: aquasecurity/[email protected]
      
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform

  test:
    runs-on: ubuntu-latest
    needs: [validate, lint]
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Go
        uses: actions/setup-go@v4
        with:
          go-version: '1.21'
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.6.0
      
      - name: Run Unit Tests
        run: |
          for module in modules/*/test; do
            if [ -f "$module/go.mod" ]; then
              cd "$module"
              go test -v -timeout 30m
              cd -
            fi
          done

  plan:
    runs-on: ubuntu-latest
    needs: [validate, lint, test]
    if: github.event_name == 'pull_request'
    strategy:
      matrix:
        environment: [dev, staging]
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
      
      - name: Terraform Plan
        run: |
          cd environments/${{ matrix.environment }}
          terraform init
          terraform plan -out=tfplan
      
      - name: Save Plan
        uses: actions/upload-artifact@v3
        with:
          name: tfplan-${{ matrix.environment }}
          path: environments/${{ matrix.environment }}/tfplan

---

CI/CD for Terraform

GitOps Workflow

Pipeline Stages

Stage 1: Pull Request Validation

on:
  pull_request:

jobs:
  validate:
    steps:
      - Checkout code
      - Terraform fmt check
      - Terraform validate
      - Run linters
      - Run unit tests
      - Generate plan
      - Comment plan on PR

Stage 2: Merge to Main (Deploy)

on:
  push:
    branches: [main]

jobs:
  deploy:
    steps:
      - Checkout code
      - Terraform init
      - Terraform plan
      - Wait for approval
      - Terraform apply
      - Post deployment tests

---

Test-Driven Development (TDD) for Infrastructure

Write tests before writing infrastructure code.

TDD Process

1. Write failing test

2. Write minimal code to pass

3. Refactor

4. Repeat

Example: TDD for a Module

Step 1: Write test first (Red)

func TestServiceModule(t *testing.T) {
	terraformOptions := &terraform.Options{
		TerraformDir: "../",
		Vars: map[string]interface{}{
			"service_name": "web",
			"port":         8080,
		},
	}

	defer terraform.Destroy(t, terraformOptions)
	terraform.InitAndApply(t, terraformOptions)

	// Test expectations
	serviceName := terraform.Output(t, terraformOptions, "service_name")
	assert.Equal(t, "web", serviceName)

	configFile := terraform.Output(t, terraformOptions, "config_file")
	assert.Contains(t, configFile, "web.conf")
}

Run: Test fails (module doesn't exist yet)

Step 2: Write minimal code (Green)

variable "service_name" {
  type = string
}

variable "port" {
  type = number
}

resource "local_file" "config" {
  filename = "${var.service_name}.conf"
  content  = "port: ${var.port}"
}

output "service_name" {
  value = var.service_name
}

output "config_file" {
  value = local_file.config.filename
}

Run: Test passes

Step 3: Refactor

Add validation, better structure, documentation.

Step 4: Add more tests, repeat

---

Common Testing Patterns

Pattern 1: Parameterized Tests

func TestMultipleEnvironments(t *testing.T) {
	testCases := []struct {
		env      string
		replicas int
	}{
		{"dev", 1},
		{"staging", 2},
		{"production", 5},
	}

	for _, tc := range testCases {
		t.Run(tc.env, func(t *testing.T) {
			terraformOptions := &terraform.Options{
				TerraformDir: "../",
				Vars: map[string]interface{}{
					"environment": tc.env,
				},
			}

			defer terraform.Destroy(t, terraformOptions)
			terraform.InitAndApply(t, terraformOptions)

			replicas := terraform.Output(t, terraformOptions, "replicas")
			assert.Equal(t, tc.replicas, replicas)
		})
	}
}

Pattern 2: Fixture-Based Testing

test/
├── fixtures/
│   ├── minimal/          # Minimal configuration
│   ├── complete/         # Full-featured configuration
│   └── invalid/          # Should fail validation
└── module_test.go

Pattern 3: Golden File Testing

Compare output to expected "golden" file:

func TestOutputMatchesGolden(t *testing.T) {
	terraform.InitAndApply(t, terraformOptions)
	
	output := terraform.Output(t, terraformOptions, "config_content")
	
	goldenFile := "testdata/expected_config.yaml"
	expected := ioutil.ReadFile(goldenFile)
	
	assert.Equal(t, string(expected), output)
}

---

Testing Best Practices

1. Test Pyramid

Many: Fast, cheap unit tests Some: Medium-speed integration tests Few: Slow, expensive end-to-end tests

2. Test What Matters

Don't test Terraform itself—test your logic:

Good:

// Test your module's behavior
assert.Equal(t, expectedPort, actualPort)
assert.Contains(t, config, "production")

Bad:

// Don't test Terraform's functionality
assert.NotNil(t, resource)  // Terraform guarantees this

3. Parallel Tests

func TestModules(t *testing.T) {
	t.Parallel()  // Run in parallel
	
	// Test code...
}

4. Clean Up

Always destroy test infrastructure:

defer terraform.Destroy(t, terraformOptions)

5. Use Unique Names

Avoid conflicts between parallel tests:

uniqueID := random.UniqueId()
terraformOptions := &terraform.Options{
	Vars: map[string]interface{}{
		"name": fmt.Sprintf("test-%s", uniqueID),
	},
}

6. Fast Feedback

Run fast tests first:

make validate  # Seconds
make lint      # Seconds
make test      # Minutes

7. Test in Isolation

Each test should be independent:

// Good: Each test has its own resources
func TestServiceA(t *testing.T) {
	// Create test-specific resources
}

func TestServiceB(t *testing.T) {
	// Create different test-specific resources
}

---

What I Learned About Testing Infrastructure

1. Testing Prevents Disasters

That Wednesday morning incident taught me: untested infrastructure code is production roulette.

Tests catch errors before they reach production.

2. Validation is Your First Line of Defense

Input validation catches 80% of errors before Terraform even runs.

Always validate inputs with clear error messages.

3. The Test Pyramid Applies to Infrastructure

• Many fast validation/lint checks

• Some unit tests

• Few integration tests

Don't skip the fast checks to write complex tests.

4. terraform plan IS a Test

Treat plan as your integration test.

If plan looks wrong, something is wrong.

5. Policy as Code Prevents Accidents

Automated policy checks prevent:

• Security violations

• Compliance issues

• Cost overruns

• Accidental deletions

6. CI/CD Makes Testing Automatic

Manual testing gets skipped.

Automated testing in CI/CD ensures every change is tested.

7. TDD Works for Infrastructure

Writing tests first clarifies what you're building.

It's slower initially but faster overall.

---

Next Steps

Congratulations! You've mastered Terraform testing:

✅ Input validation ✅ terraform validate and fmt ✅ Static analysis and linting ✅ Unit testing with Terratest ✅ Integration testing ✅ Policy as code ✅ Comprehensive testing pipeline ✅ CI/CD for Terraform ✅ TDD for infrastructure

Practice Exercises

Exercise 1: Add Validation

1. Review your modules
2. Add validation to all variables
3. Test with invalid inputs
4. Improve error messages

Exercise 2: Set Up Linting

1. Install TFLint and tfsec
2. Configure rules
3. Fix all issues
4. Add to CI/CD

Exercise 3: Write Unit Tests

1. Choose a module
2. Write Terratest unit tests
3. Test happy path
4. Test edge cases
5. Test error handling

Coming Up Next

In Article 9: Security and Secrets Management - Protecting Your Infrastructure, we'll explore:

• Securing Terraform state

• Secret management strategies

• HashiCorp Vault integration

• Encryption patterns

• Security scanning

• Compliance and auditing

Testing ensures quality. Security ensures safety.

---

This Week's Challenge: Add comprehensive testing to your Terraform projects. Set up validation, linting, and at least one automated test. Integrate into CI/CD.

See you in Article 9! 🧪

---

"Testing infrastructure felt optional until that Wednesday morning. Now, every line of Terraform code gets validated, linted, and tested before it touches production. No exceptions." - Me, converted to infrastructure testing