Terraform Test Coverage Assessment
Overview
Test quality assessment for Terraform components using the native terraform test framework (.tftest.hcl files). Evaluates coverage across 6 dimensions and provides patterns for mock_provider, override_resource, and plan-only assertions.
When to Use
- Reviewing existing
.tftest.hclfiles for coverage gaps - Designing new tests for a Terraform component
- After adding new variables, resources, or feature flags
- Assessing whether a component is adequately tested before release
When NOT to Use
- For non-native test frameworks (Terratest, kitchen-terraform)
- For syntax or formatting checks -- use
terraform validate/terraform fmt - For security auditing -- use the
terraform-security-auditskill - For module API design or variable naming reviews
- When the component has no
.tftest.hclfiles and you are not asked to create them
Coverage Dimensions
Assess each component against these 6 dimensions (see test-patterns.md for HCL examples):
- Happy Path --
runblock withcommand = plan, valid inputs, assertions on key resource attributes - Variable Validation -- Every
validationblock has a test usingexpect_failures - Feature Toggles -- Every enable/disable flag tested in both states
- Edge Cases -- Boundary values, empty collections, single-AZ, all features disabled
- CIDR Math -- Subnet CIDRs do not overlap, fit within VPC CIDR, correct AZ distribution (N/A for non-networking)
- Naming Conventions -- Name tags and environment/stage propagate consistently
Workflow
- Discover tests: Find all
.tftest.hclfiles in the component - Inventory variables: Read
variables.tfto list all required variables, validation blocks, and feature toggle flags - Map coverage: For each
runblock, determine which dimension(s) it covers - Identify gaps: Cross-reference dimensions against existing tests. Flag missing coverage
- Assess quality: Check assertion depth -- tests should verify specific attributes, not just "plan succeeds"
- Produce report: Use the template from
templates.md
Critical Rules
- Every
validationblock MUST have a matchingexpect_failurestest - Every boolean feature flag MUST be tested in both states
- Happy path tests MUST assert on specific resource attributes, not just plan success
mock_provideris required for plan-only tests -- do not rely on real AWS credentials- IPAM components need
override_resourceto provide mock CIDR values since allocations happen at apply time
Common Mistakes
| Mistake | Why It Happens | Correct Approach |
|---|---|---|
| Happy path test with zero assertions | Developer assumes "plan succeeds" is sufficient | Assert on specific resource attributes (count, CIDR, tags) |
Missing expect_failures for validations |
Validation blocks seem self-documenting | Every validation block needs an explicit negative test |
| Testing feature toggle in one state only | Enabled state is the default, so it "works" | Test both enabled and disabled; verify resource count is 0 when disabled |
| Hardcoding AZ names without mock | Tests fail in different regions | Use override_data on data.aws_availability_zones |
| Skipping CIDR overlap checks | Subnets "look right" in small configs | Use distinct() assertion to verify no CIDR overlap programmatically |
| No edge case for single AZ | Multi-AZ is the common path | Single-AZ is a valid deployment; test az_count = 1 explicitly |
Supporting Files
test-patterns.md-- HCL code examples for each coverage dimension and mock_provider patternstemplates.md-- Coverage assessment output template
Source: infraspecdev/tesseract — distributed by TomeVault.