provider-test-patterns

Write Terraform provider acceptance tests using terraform-plugin-testing with the Plugin Framework.

1|1|Updated Dec 30, 2025
One-click install
npx skills add https://github.com/anyscale/terraform-provider-anyscale --skill provider-test-patterns-anyscale
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: provider-test-patterns
Source: https://github.com/anyscale/terraform-provider-anyscale/tree/main/.claude/skills/provider-test-patterns
Command: npx skills add https://github.com/anyscale/terraform-provider-anyscale --skill provider-test-patterns-anyscale

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing acceptance tests for Terraform providers built with the Plugin Framework involves many moving parts: TestCase and TestStep configuration, state checks, plan checks, import verification, sweepers, and ephemeral resource testing. This Skill provides proven patterns and reference material so you can write correct, idiomatic provider tests without digging through framework documentation. ## Core Features & Use Cases - Test Structure Patterns: Covers TestCase/TestStep fields, provider factories, config helpers with numbered format verbs, and the plan-apply-refresh test lifecycle. - Modern Assertions: Guides use of ConfigStateChecks with statecheck, knownvalue types, tfjsonpath navigation, plancheck, and CompareValue for cross-step assertions, plus custom StateCheck implementations for exists and disappears checks. - Scenario Coverage: Includes patterns for basic, update, import (ImportStateKind), disappears, validation (ExpectError), regression tests, sweepers, and ephemeral resource testing with the echoprovider package. - Use Case: You are adding a new resource to a Terraform provider and need an acceptance test that creates the resource, updates it, verifies import, and checks destroy. This Skill gives you the complete test skeleton and assertion patterns to do it correctly. ## Quick Start Ask the AI to write an acceptance test for a Terraform provider resource using terraform-plugin-testing with state checks and an import verification step.

Frequently Asked Questions about provider-test-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write Terraform provider acceptance tests with terraform-plugin-testing?▼

Define a TestCase with PreCheck, ProtoV6ProviderFactories, CheckDestroy, and Steps containing TestStep entries with Config and ConfigStateChecks. Use resource.ParallelTest by default so tests run concurrently.

What is the difference between ConfigStateChecks and Check in terraform-plugin-testing?▼

ConfigStateChecks is the modern, preferred approach using statecheck.StateCheck implementations with type-safe knownvalue assertions and aggregated error reporting. Check uses legacy TestCheckFunc and is still required for CheckDestroy, but the two should not be mixed in the same step.

How do I test Terraform import functionality in acceptance tests?▼

Add a TestStep after a config step with ImportState set to true, ImportStateVerify set to true, ResourceName pointing to the resource address, and ImportStateKind set to resource.ImportBlockWithID for import block generation.

How do I test ephemeral resources in Terraform providers?▼

Use the echoprovider package to capture ephemeral data into a managed resource's state, then assert on it with standard ConfigStateChecks. Gate tests with tfversion.SkipBelow(tfversion.Version1_10_0) since ephemeral resources require Terraform 1.10 or newer.

How do I clean up leaked resources from failed Terraform acceptance tests?▼

Register sweepers with resource.AddTestSweepers and add resource.TestMain(m) in a TestMain function. Run them with go test using the -sweep flag, and declare Dependencies on parent sweepers so child resources are deleted first.

Why does my Terraform acceptance test fail with a non-empty plan after apply?▼

The framework runs plan, apply, refresh, and a final plan for each step; a diff in the final plan fails the test. This usually indicates drift or inconsistent state, and you can set ExpectNonEmptyPlan only when the diff is intentional, such as in disappears tests.