The IaC testing landscape

Native tests, InSpec, Checkov.

Advanced10 min · lesson 12 of 12

Terratest is the most popular IaC integration-testing tool, but it sits among several approaches worth knowing. Terraform now has native tests (.tftest.hcl files run by terraform test) — no Go required, good for plan- and apply-level assertions within Terraform itself. Kitchen-Terraform (Test Kitchen + InSpec) is the Ruby-based alternative, pairing deploys with InSpec assertions. And the static layer (Checkov, tfsec/Trivy, OPA/Conftest) is complementary, not competing — it answers different questions cheaply.

Ways to test IaC

integration (real deploy)

Terratest

Go, broad toolkit

Terraform native test

HCL, no Go

kitchen-terraform + InSpec

Ruby

static (no deploy)

Checkov / Trivy

misconfig

OPA / Conftest

policy on plan

Static answers “is it configured right?” cheaply; integration answers “does it actually work?” Use both, weighted to the base.

Choosing and combining

For teams already writing Go, Terratest’s rich module ecosystem (cloud SDK assertions, http/k8s/helm/ssh helpers) is hard to beat for real behavioral tests. Terraform native tests are attractive when you want tests in HCL without a second language, especially for plan-level checks. InSpec (its own course) shines for compliance-style “the running system meets this control” assertions. The mature answer is a pyramid: heavy static/policy at the base, native or plan tests in the middle, and a focused Terratest layer on top for the behavior that truly needs a deploy.

Integration tests complement, never replace, static checks

Terratest proves behavior but is slow, costly, and narrow (you test a few cases); static scanning and policy are fast, free, and broad (every resource, every commit). Neither substitutes for the other. A team that only does Terratest misses cheap wide coverage; one that only scans never proves anything works. Build the whole pyramid, and let each layer do what it is best at.

Terratest in CI/CDFinish · self-test