Skill

terraform-test-coverage

Use when reviewing Terraform test files (.tftest.hcl), assessing test coverage, or designing new tests for components using mock_provider and plan-only assertions

From shield

Install

Run in your terminal

npx claudepluginhub infraspecdev/tesseract --plugin shield

Tool Access

This skill uses the workspace's default tool permissions.

Supporting Assets

View in Repository

templates.md

test-patterns.md

Skill Content

Similar Skills

continuous-learning-v2

9 files

Observes Claude Code sessions via hooks to create atomic project-scoped instincts with confidence scores, evolving them into skills, commands, or agents.

ecc

144.6k

continuous-learning

2 files

Automatically extracts reusable patterns like error resolutions, workarounds, and debugging techniques from Claude Code sessions via Stop hook, saving them as learned skills for reuse.

ecc

144.6k

continuous-agent-loop

Provides patterns for continuous autonomous agent loops with loop selection, quality gates, evals, recovery controls, and failure mitigation. Useful for production AI agent workflows.

ecc

144.6k

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitMar 14, 2026

Actions

View Source View Plugin View on GitHub View README

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.hcl files 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-audit skill
For module API design or variable naming reviews
When the component has no .tftest.hcl files 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 -- run block with command = plan, valid inputs, assertions on key resource attributes
Variable Validation -- Every validation block has a test using expect_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.hcl files in the component
Inventory variables: Read variables.tf to list all required variables, validation blocks, and feature toggle flags
Map coverage: For each run block, 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 validation block MUST have a matching expect_failures test
Every boolean feature flag MUST be tested in both states
Happy path tests MUST assert on specific resource attributes, not just plan success
mock_provider is required for plan-only tests -- do not rely on real AWS credentials
IPAM components need override_resource to 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 patterns
templates.md -- Coverage assessment output template