The module toolkit

terraform, http-helper, aws, k8s.

Advanced12 min · lesson 3 of 12

Terratest is a collection of modules, each a helper library for a technology, and knowing what exists saves you writing glue. terraform drives Terraform. http-helper makes HTTP requests with retries (great for “is the service up?”). aws/azure/gcp query cloud resources directly to assert they exist and are configured right. k8s and helm test Kubernetes. There are also ssh, docker, and retry modules. You compose these to express “deploy X, then verify Y.”

toolkit example

import (
  "github.com/gruntwork-io/terratest/modules/terraform"
  http_helper "github.com/gruntwork-io/terratest/modules/http-helper"
  "github.com/gruntwork-io/terratest/modules/aws"
)
// after apply:
url := terraform.Output(t, opts, "alb_url")
http_helper.HttpGetWithRetry(t, url, nil, 200, "OK", 30, 5*time.Second)  // poll until 200
region := "us-east-1"
bucket := terraform.Output(t, opts, "bucket_id")
aws.AssertS3BucketVersioningEnabled(t, region, bucket)   // query AWS directly

Assert on behavior and on the cloud

Two complementary assertion styles. Behavioral: hit the deployed endpoint with http-helper and confirm it returns what it should — proving the whole stack works end to end. Cloud-state: use the aws/azure/gcp modules to query the provider API and confirm a resource has the security-relevant configuration you expect (encryption on, versioning enabled, no public access). The best tests do both — the thing works, and it is configured safely.

Prefer the provider modules over parsing CLI output

It is tempting to shell out to aws s3api ... and parse the text, but the aws/azure/gcp modules query the provider SDK directly and return typed results, which is more robust and readable than scraping CLI output that can change format. Reach for the built-in cloud modules for state assertions; drop to raw calls only for something they do not cover.

Your first Terraform testCleanup & defer destroy