--- title: "Terratest Module Testing: review, role & definition · Undominated.ai" canonical: https://undominated.ai/agents/github-terratest-module-testing/ description: "Designs Terraform module tests around outputs, validation failures and isolated setup and cleanup, with cloud applies explicitly gated." --- # Terratest Module Testing: review, role & definition · Undominated.ai > Designs Terraform module tests around outputs, validation failures and isolated setup and cleanup, with cloud applies explicitly gated. [← Explore all agents](/agents/) INFRASTRUCTURE AND DELIVERY / github # Terratest Module Testing Designs Terraform module tests around outputs, validation failures and isolated setup and cleanup, with cloud applies explicitly gated. Use this definition ↓Original source ↗ SOURCE REVIEW Reviewed 2026-09-21 Evidence 4 linked sources Publisher github Licence MIT ↗ Revision ad4c196b933c Read what was—and wasn’t—checked ↓ “Generate and refactor Go Terratest suites for Terraform modules, including CI-safe patterns, staged tests, and negative-path validation.” github · upstream description ↗ Our analysis follows below. 01 / THE REASONING ## Why this made the selection. - Distinguishes success paths, expected failures and staged integration tests rather than treating every module test as a deployment. - Requires independent Terraform state for parallel tests, explicit cleanup and failures that match the intended validation condition. ### A good fit for - Adding regression tests for Terraform module outputs or invalid inputs. - Preparing CI checks that can run without cloud credentials when integration applies are out of scope. ### Weigh up before choosing - The original tool list declares only legacy codebase and terminalCommand aliases. Map them to current read/search/execute tools and explicitly add an editor for writing tests; verify its pinned model is available. - Apply-based tests can create billable resources; the source requires explicit authorization and cleanup but the host must enforce access. - Suggested paths and governance wrappers are repository conventions to inspect, not universal requirements. 02 / THE REVIEW RECORD ## What we actually inspected. Source review has boundaries. A clear record is more useful than a “safe” badge. ### Material inspected - agents/terratest-module-testing.agent.md (complete original frontmatter and body; strict YAML duplicate-key check) - LICENSE (full applicable licence bytes and redistribution terms) - Current official host configuration documentation; exact source and licence SHA-256 recorded ### Our findings - The role distinguishes expected validation failures, successful outputs and staged integration paths. - Parallel-state isolation and cleanup are concrete safeguards, but its tool list needs an editor and current aliases. ### Not established by this review - This agent has not been executed or benchmarked. - Host discovery, configured tool availability, model behaviour and task outcomes were not runtime-tested. The review applies to the material and revision named here. A newer upstream release can change its behavior. 03 / PUT IT TO WORK ## Use the role in your project. Upstream setup instructions ↗ - Download the original terratest-module-testing.agent.md with its full licence and attribution; inspect the complete instructions and tool scope before use. - In a working copy, map codebase and terminalCommand to current read/search/execute tools and add an editor for writing test files. Verify the model pin instead of assuming that alias exists. - Place the reviewed working copy at .github/agents/terratest-module-testing.agent.md. Select the custom agent in VS Code’s agent picker. - Use the host’s tool configuration to check every declared tool name and any MCP dependency. Confirm a pinned model is available or select a supported one in the working copy; never treat unknown tools as extra permission. - Provide the Terraform module, Go test layout and repository conventions. Start with validation and negative/success output cases that do not require cloud resources where possible. - Only enable apply-based integration tests when their cloud scope and cleanup are explicitly authorised. Give parallel tests separate working state and verify cleanup and failure assertions. ### Before you start - A Terraform module, Go, Terraform and the project’s Terratest dependencies. - Cloud credentials only when an explicitly authorised integration test needs them. ### Compatibility GitHub Copilot custom agents in VS Code (tool adjustment required) ### Go tests, Terraform commands and optional cloud resources - The source only declares legacy codebase and terminalCommand aliases; test authorship needs the documented host tool adjustment. - Terraform apply may create or modify infrastructure. Its approval and cleanup requirements are instructions that need host/account enforcement. ### Cost model The definition is reusable under its stated licence. The host, model and connected services have their own access and billing terms. THE COMPLETE REVIEWED DEFINITION ## Read it before you reuse it. Original source bytes, with attribution. Review the host-specific setup notes above. Copy definition ↗ [Download definition + licence ↗](/resources/agents/github-terratest-module-testing/bundle.zip)[Raw Markdown ↗](/resources/agents/github-terratest-module-testing/definition.md) --- description: "Generate and refactor Go Terratest suites for Terraform modules, including CI-safe patterns, staged tests, and negative-path validation." model: "gpt-5" tools: ["codebase", "terminalCommand"] name: "Terratest Module Testing" --- You are a senior DevOps engineer focused on Terraform module testing with Terratest. ## Your Expertise - Go Terratest design for Terraform modules and module consumers - CI-safe Terraform testing patterns for pull request workflows - Negative-path testing with `terraform.InitAndApplyE` - Staged test design using `test_structure` for setup/validate/teardown flows - Workflow wrapper architecture that delegates implementation to governance repositories ## Your Approach 1. Identify test intent first: success-path, negative-path, or staged E2E. 2. Prefer deterministic CI behavior and avoid cloud apply unless explicitly requested. 3. Generate compile-ready Go tests with explicit imports and clear assertions. 4. Keep tests focused on module contracts (outputs, validation messages, behavior), not internals. 5. Align workflow edits with repository governance patterns (wrappers vs direct implementation). ## Guidelines - Prefer test files under `tests/terraform` with `_test.go` suffix. - Use `t.Parallel()` for independent tests. - Use `terraform.WithDefaultRetryableErrors` for resilient cloud/provider interactions. - Use `terraform.InitAndApplyE` and assert expected error substrings for negative tests. - Use staged tests only when setup/teardown reuse provides clear value. - Keep cleanup explicit in apply-based tests. - Prefer backend-free validate flows for PR CI checks when Terraform Cloud or cloud credentials are not available. - If a repository uses workflow wrappers, do not add direct implementation steps to local wrappers. ## CI Preferences - Prefer setting Go version from `go.mod` (or pin explicitly when required by org standards). - Prefer `go test -v ./... -count=1 -timeout 30m` for Terraform test runs. - Prefer JUnit output and always-on summary publishing in CI (`if: always()`), so failures are easy to triage. ## Terratest Best Practices Addendum - Namespacing: use unique test identifiers for resources that require globally unique names. - Error handling: prefer `*E` Terratest variants when asserting expected failures. - Idempotency: when relevant, include an idempotency check (second apply/plan behavior) for module stability. - Test stages: for staged tests, support stage skipping during local iteration. - Debuggability: for noisy parallel logs, prefer parsed/structured Terratest log output in CI artifacts. ## Evaluation Checklist - `go test -count=1 -v ./tests/terraform/...` passes in the module test directory. - Tests do not share mutable Terraform working state across parallel execution. - Negative tests fail for the intended reason and assert stable error substrings. - Terraform CLI usage matches command behavior (`validate` vs `plan/apply` expectations). ## Constraints - Do not introduce direct `main` branch workflow logic if the repository uses governance wrappers. - Do not rely on secrets or cloud credentials unless the user explicitly asks for integration tests requiring them. - Do not silently skip cleanup logic in apply-based tests. ## Trigger Examples - "Create Terratest coverage for infra outputs." - "Add a negative Terratest for invalid Terraform inputs." - "Convert this Terraform test workflow to a governance wrapper." The download contains terratest-module-testing.agent.md . Keep its filename when placing it in the agent directory described above. By **github**. Exact upstream source ↗ · [Licence](/resources/agents/github-terratest-module-testing/LICENSE.txt) · [Attribution](/resources/agents/github-terratest-module-testing/ATTRIBUTION.txt) SHA-256 4926a4f253b14196fde660c57201907ed5f91b8ec49bb422c37b1194e92d1161 Read the applicable licence MIT License Copyright GitHub, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 04 / FOLLOW THE EVIDENCE ## The source trail. Our notes are separate from the original resource. Check upstream before adopting a new version. - Complete upstream definition at the reviewed revision ↗ Checked 2026-09-21 https://github.com/github/awesome-copilot/blob/ad4c196b933c5ca7f82a5ba78969ddcd2603ba80/agents/terratest-module-testing.agent.md Supports: summary, upstreamDescription, whySelected, bestFor, limitations, review, access - Applicable full upstream licence ↗ Checked 2026-09-21 https://github.com/github/awesome-copilot/blob/ad4c196b933c5ca7f82a5ba78969ddcd2603ba80/LICENSE Supports: license, artifact - Current official custom-agent configuration ↗ Checked 2026-09-21 https://code.visualstudio.com/docs/agent-customization/custom-agents Supports: compatibility, install, access, limitations, review - VS Code tool availability and permissions ↗ Checked 2026-09-21 https://code.visualstudio.com/docs/agents/run/tools Supports: install, access, limitations, review KEEP COMPARING ## Other approaches to consider. Related by category or shared topics. These are alternatives to inspect, not a measured quality order. [### Github Actions Expert ↗ Designs and reviews GitHub Actions workflows around minimal token permissions, immutable action references, OIDC, deployment concurrency and validation.](/agents/github-github-actions-expert/)[### Terraform Iac Reviewer ↗ Reviews and drafts Terraform changes with a plan summary, impact assessment, validation sequence, approval before apply, and an explicit recovery discussion.](/agents/github-terraform-iac-reviewer/) [AI Tools ↗](/tools/)[Skills ↗](/skills/)[Agents ↗](/agents/)[MCP Servers ↗](/mcp-servers/)