القائمة
Generate tests for Terraform modules. Use everytime tests are missing or need to be updated.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | terraform-tests |
| description | Generate tests for Terraform modules. Use everytime tests are missing or need to be updated. |
| metadata | {"author":"pagopa-dx","version":"1.1"} |
| compatibility | requires terraform, go, and access to the internet |
This skill generates comprehensive test suites for Terraform modules following HashiCorp's Terraform Testing Framework best practices. Tests are organized into four layers: Unit, Contract, Integration, and End-to-End (E2E).
For AI Agents: This skill references detailed documentation files. All relative paths (e.g.,
reference/unit-tests.md) are relative to.github/skills/terraform-tests/from the workspace root. When you need detailed information about a specific test layer, useread_fileto load the referenced documentation file.
Based on HashiCorp's Testing Framework:
tests/
├── unit.tftest.hcl # Unit tests (mocked)
├── contract.tftest.hcl # Contract tests (mocked)
├── integration.tftest.hcl # Integration tests (real resources)
├── e2e_test.go # E2E tests (Terratest + workloads)
├── go.mod # Go dependencies for E2E tests
├── README.md # Test documentation
├── setup/ # Shared setup module for integration tests only
│ ├── main.tf
│ ├── variables.tf
│ ├── outputs.tf
│ ├── providers.tf
│ └── README.md
└── apps/ # Test applications for E2E tests
└── <scenario_name>/ # App exposes HTTP APIs called by e2e_test.go
├── Dockerfile
├── project.json
├── README.md
└── src/
├── go.mod
└── main.go
Tests are run using NX commands:
nx run <module-name>:test:unit
nx run <module-name>:test:contract
nx run <module-name>:test:integration
nx run <module-name>:test:e2e
Important: After modifying unit and contract tests, always execute them to verify they pass. Integration and E2E tests are slow and should not be run during development, only in CI/CD.
expect_failures, test validation rulestests/setup/ module, use "int" in domain namesinfra/resources/_modules/testingexamples/, call test app APIs, verify behaviorfixtures.tf (infrastructure) + mut.tf (module under test)When creating a new Terraform module:
fixtures.tf and mut.tf for E2E testspnpm nx release planWhen modifying a module with modern tests:
pnpm nx release plan, update mut.tf if neededWhen a module has legacy tests (single file, no modern structure):
pnpm nx release planinfra/resources/_modules/testingnx run <module-name>:test:<layer>module_name_feature_being_tested patternsource = "../.." during development, registry+version before commitpnpm nx release plan for patch bump when adding/modifying tests| Aspect | Integration Tests | E2E Tests |
|---|---|---|
| Infrastructure | Uses tests/setup/ module | Uses examples/fixtures.tf |
| Module source | Direct module reference | Module in examples/mut.tf |
| Test apps | Not used | Required (in tests/apps/) |
| Domain name | "int" | "e2e" |
| Separation | Separate from E2E infrastructure | Separate from integration infrastructure |
| Purpose | Test module in isolation | Test complete scenarios with workloads |
infra/resources/_modules/testingthis file contains unit tests or 3. Development use case when the run name already conveys that); comments are fine when they add necessary context such as non-obvious intent, workarounds, assumptions, or edge casesCreate and update a structured Design Review / Software Requirements Specification (DR/SRS). Use whenever a user asks for a Design Review, DR, SRS, solution design, technical requirements document, architecture review, or to turn an accepted RFC into the operational design. Write Markdown first, preserve stable IDs, expose gaps without inventing decisions, invoke uc-engraver when detailed Use Cases are requested, and hand confirmed Confluence publication to the confluence-librarian skill.
Project approved DR/SRS and Use Case contracts into a reviewable Jira backlog. Use whenever a user asks to create, decompose, refine, synchronize, or update Jira Epics, User Stories, or technical Tasks from a PRD, DR/SRS, Use Case, JTBD, acceptance check, RFC, or requirements document. Propose multiple cohesive Epics that fit a few sprints, write actor-facing Stories sized for one two-week sprint, separate enabling work into Tasks, preserve source traceability, and require explicit confirmation before Jira mutations.
Create and update structured Use Case child documents for a parent Design Review / Software Requirements Specification (DR/SRS). Use whenever a user asks to define, write, refine, synchronize, or publish a Use Case, UC, scenario, acceptance checks, or detailed behavior from a PRD, DR/SRS, JTBD, Service Blueprint, Figma, RFC, contract, or task intake. Preserve stable UC/AC IDs, reuse actor names exactly from the linked PRD, expose gaps without inventing behavior, update and verify the parent DR/SRS catalog, and hand confirmed Confluence publication to confluence-librarian.
Publish and update prepared pages and document artifacts in Confluence without losing structure or traceability. Use whenever a user asks to publish, create, update, translate, or synchronize Markdown, HTML, or another readable document to Confluence, including hierarchical child pages under a parent catalog. Require explicit confirmation before irreversible publication and preserve headings, tables, links, statuses, IDs, and intentional gaps.
Write and update a structured Product Requirements Document (PRD) from gathered product material. Use when a product manager wants to turn discovery notes, meeting summaries, strategy input, or a rough product document into a Confluence-compatible PRD covering needs, actors, JTBD, goals, metrics, guardrails, dependencies, constraints, feasibility red flags, design discovery, open questions, and support readiness. Preserve stable English IDs, manage explicit draft-to-review readiness, and offer optional Confluence publication only after writing.
Build or extend backend tests for Node.js/TypeScript services with real runtimes, Testcontainers dependencies, optional .env.test cloud services, and integration and/or record-replay coverage. Use for integration tests, live contracts, freeze-before-refactor, VCR/golden-master, cassette record/verify, Azure Functions harnesses, replacing mock-heavy tests, or adding scenarios to an existing backend-test harness. Always use when choosing between integration and record-replay.