Terraform test framework (1.6+) - Commands & Configuration

Introduction

Testing your Terraform code helps catch mistakes before applying changes. Terraform 1.6+ includes a built-in test framework to run automated tests on your infrastructure code.

When you want to verify that your Terraform modules create the expected resources.

When you need to catch errors early before deploying infrastructure.

When you want to automate checks for resource attributes after apply.

When you want to ensure your infrastructure code works as expected after changes.

When you want to integrate infrastructure tests into your CI/CD pipeline.

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.6"
}

resource "null_resource" "example" {
  provisioner "local-exec" {
    command = "echo Hello Terraform Test"
  }
}

// Test file
// terraform test framework uses *_test.go files, but here is a minimal example
// This file is for demonstration only and should be placed in tests/ folder

This Terraform configuration defines a simple null_resource that runs a local command. It serves as the resource to test.

The terraform block ensures the version is 1.6 or higher to support the test framework.

Tests are written in Go files with *_test.go suffix, typically placed in a tests/ directory alongside your Terraform code.

Commands

Initializes the Terraform working directory and downloads required providers. This step is needed before running any Terraform commands.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/null...

- Installing hashicorp/null v3.1.0...

- Installed hashicorp/null v3.1.0 (signed by HashiCorp)



Terraform has been successfully initialized!

Applies the Terraform configuration to create the defined resources. The -auto-approve flag skips manual approval to speed up testing.

Terminal

terraform apply -auto-approve

Expected Output

null_resource.example: Creating...

null_resource.example: Provisioning with 'local-exec'...

Hello Terraform Test

null_resource.example: Creation complete after 0s



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the apply without prompting

Runs the Terraform test framework to execute automated tests defined for your Terraform code. This checks if your resources behave as expected.

Terminal

terraform test

Expected Output

=== RUN   TestExample

--- PASS: TestExample (0.01s)

PASS

ok  terraform/tests 0.015s

Destroys all resources created by Terraform to clean up after tests. The -auto-approve flag skips manual confirmation.

Terminal

terraform destroy -auto-approve

Expected Output

null_resource.example: Destroying...

null_resource.example: Destruction complete after 0s



Destroy complete! Resources: 1 destroyed.

→

-auto-approve - Automatically approve the destroy without prompting

Key Concept

If you remember nothing else from this pattern, remember: Terraform 1.6+ lets you write and run automated tests to verify your infrastructure code before applying changes.

Common Mistakes

Running terraform test without initializing the directory first

The test framework requires providers and modules to be initialized, or tests will fail to run.

Always run terraform init before terraform test to prepare the working directory.

Not writing test files with the correct *_test.go naming and location

Terraform test framework only detects Go test files with *_test.go suffix in the correct folder.

Place test files in a tests/ folder and name them with *_test.go suffix to be recognized.

Forgetting to clean up resources after tests

Leaving test resources running can cause unexpected costs and clutter your environment.

Run terraform destroy -auto-approve after tests to remove created resources.

Summary

Initialize your Terraform directory with terraform init before running tests.

Apply your Terraform code with terraform apply to create resources for testing.

Run terraform test to execute automated tests on your infrastructure code.

Clean up test resources with terraform destroy to avoid leftover infrastructure.

Practice

1. What is the main purpose of the Terraform test framework introduced in version 1.6+?

easy

A. To monitor cloud resources for performance issues

B. To deploy infrastructure faster without manual approval

C. To write automated tests that check your infrastructure code works as expected

D. To replace Terraform CLI commands with a graphical interface

Solution

1. Step 1: Understand Terraform test framework purpose

   The framework is designed to let you write tests that run your Terraform code and verify resource attributes automatically.

2. Step 2: Compare options with framework purpose

   Only To write automated tests that check your infrastructure code works as expected correctly describes writing automated tests for infrastructure code. Other options describe unrelated features.

3. Final Answer:

   To write automated tests that check your infrastructure code works as expected -> Option C

4. Quick Check:

   Test framework purpose = automated infrastructure tests [OK]

Hint: Focus on testing infrastructure code correctness [OK]

Common Mistakes:

• Confusing testing with deployment speed
• Thinking it replaces CLI commands
• Mixing testing with monitoring

2. Which of the following is the correct syntax to define a Terraform test block in version 1.6+?

easy

A. module "test" { ... }

B. terraform_test "example" { ... }

C. resource "test" "example" { ... }

D. test "example" { ... }

Solution

1. Step 1: Recall Terraform test block syntax

   Terraform 1.6+ uses the test "name" { ... } block to define tests.

2. Step 2: Eliminate incorrect syntax options

   Options B, C, and D use incorrect block types or resource/module keywords not related to tests.

3. Final Answer:

   test "example" { ... } -> Option D

4. Quick Check:

   Test block syntax = test "name" [OK]

Hint: Look for the exact 'test' block keyword [OK]

Common Mistakes:

• Using resource or module instead of test block
• Adding extra prefixes like terraform_test
• Confusing test block with resource block

3. Given this Terraform test snippet, what will the test check?

test "check_instance" {
  config = {
    resource "aws_instance" "example" {
      ami           = "ami-123456"
      instance_type = "t2.micro"
    }
  }
  check { 
    resource = "aws_instance.example"
    attribute = "instance_type"
    equals = "t2.micro"
  }
}

medium

A. It checks if the AMI ID is 't2.micro'

B. It checks if the instance type of aws_instance.example is 't2.micro'

C. It verifies the instance is running

D. It validates the resource name is 'aws_instance.example'

Solution

1. Step 1: Analyze the check block

   The check block specifies resource "aws_instance.example", attribute "instance_type", and expects it to equal "t2.micro".

2. Step 2: Match check with options

   It checks if the instance type of aws_instance.example is 't2.micro' correctly states the test checks the instance_type attribute equals "t2.micro". Other options misunderstand attribute or resource checks.

3. Final Answer:

   It checks if the instance type of aws_instance.example is 't2.micro' -> Option B

4. Quick Check:

   Check attribute equals instance_type = t2.micro [OK]

Hint: Focus on attribute and equals fields in check block [OK]

Common Mistakes:

• Confusing AMI ID with instance type
• Assuming runtime status is checked
• Misreading resource name as attribute

4. This Terraform test code fails to run. What is the most likely error?

test "fail_test" {
  config = {
    resource "aws_s3_bucket" "bucket" {
      bucket = "my-bucket"
    }
  }
  check {
    resource = "aws_s3_bucket.bucket"
    attribute = "name"
    equals = "my-bucket"
  }
}

medium

A. The attribute 'name' does not exist for aws_s3_bucket resource

B. The resource block is missing required 'region' argument

C. The test block name cannot contain underscores

D. The equals value must be a number, not a string

Solution

1. Step 1: Check attribute correctness

   The aws_s3_bucket resource uses 'bucket' as the attribute for bucket name, not 'name'. Using 'name' causes the test to fail.

2. Step 2: Verify other options

   Region is usually set in provider, not required here. Test names can have underscores. Equals can be string. So only attribute error is valid.

3. Final Answer:

   The attribute 'name' does not exist for aws_s3_bucket resource -> Option A

4. Quick Check:

   Attribute must match resource schema [OK]

Hint: Check attribute names match resource documentation [OK]

Common Mistakes:

• Using wrong attribute names
• Assuming region is required in resource block
• Thinking test names have naming restrictions
• Confusing data types in equals

5. You want to write a Terraform test that verifies multiple attributes of an AWS EC2 instance, including instance_type and tags. Which approach correctly uses the Terraform test framework to check both attributes in one test?

hard

A. Use multiple check blocks inside one test block, each checking one attribute

B. Create separate test blocks for each attribute check

C. Combine attributes in one check block using a list for attribute and equals

D. Use a single check block with a map for attribute and equals

Solution

1. Step 1: Understand multiple attribute checks in Terraform tests

   The Terraform test framework allows multiple check blocks inside one test block to verify different attributes separately.

2. Step 2: Evaluate options for correctness

   Using multiple check blocks inside one test block, each checking one attribute, correctly verifies different attributes separately. Combining attributes into a single check block using a list or map is not supported. Creating separate test blocks for each attribute check works but is less efficient.

3. Final Answer:

   Use multiple check blocks inside one test block, each checking one attribute -> Option A

4. Quick Check:

   Multiple checks = multiple check blocks [OK]

Hint: Use one check block per attribute inside test [OK]

Common Mistakes:

• Trying to check multiple attributes in one check block
• Splitting checks into many test blocks unnecessarily
• Using unsupported data structures in check block