provider-test-patterns

Overview of provider-test-patterns skill

provider-test-patterns is a Terraform provider acceptance testing skill for teams using terraform-plugin-testing with the Plugin Framework. It helps you write, review, and debug provider tests with less trial and error than a generic prompt, especially when you need the right TestCase, TestStep, state checks, plan checks, import verification, or sweeper setup.

Best fit and job to be done

Use the provider-test-patterns skill when your real task is: “I need a reliable acceptance test pattern for a provider resource, and I want to know which test shape fits this scenario.” It is most useful for backend development work on providers, where the hard part is not syntax alone but choosing the right assertion strategy and lifecycle coverage.

What it covers well

The provider-test-patterns skill is strongest when you need guidance on:

• test lifecycle flow across plan, apply, refresh, and destroy
• TestCase and TestStep structure
• ConfigStateChecks, plancheck, and CompareValue
• import testing with ImportStateKind
• sweepers and cleanup safety
• scenario patterns such as basic, update, disappears, validation, and regression
• ephemeral resource testing with the echoprovider pattern

When it is a strong install

Install provider-test-patterns if you want opinionated patterns that map directly to Terraform provider acceptance tests, especially for backend development teams already working in the Plugin Framework. It is a better fit than a general prompt when the main risk is missing a required check, using the wrong assertion type, or structuring tests in a way that is hard to maintain.

How to Use provider-test-patterns skill

Install and load it in context

Use the repository install flow for your skill manager, then open SKILL.md first. The upstream skill does not define its own install command, so the practical provider-test-patterns install step is to add the skill through your agent’s skills workflow and then read the skill plus the supporting references.

Start from the test shape, not the code

The best provider-test-patterns usage workflow is to describe the scenario before asking for code. State:

• resource type and lifecycle stage
• whether this is basic, update, import, disappears, validation, or regression coverage
• what must be asserted in state or plan
• whether cleanup is required via sweepers
• whether the case involves ephemeral resources

That gives the skill enough structure to choose between ordinary config checks, statecheck, plancheck, or cross-step comparisons.

Read these files first

For fast adoption, read in this order:

1. SKILL.md for the main pattern set and lifecycle guidance
2. references/checks.md for statecheck, plancheck, known values, and comparers
3. references/ephemeral.md if the resource is ephemeral or uses echoprovider
4. references/sweepers.md if leaked resources are a concern

Strong prompt pattern

A good prompt for provider-test-patterns should include the resource, the failure mode, and the desired assertion style. For example:

Write an acceptance test for example_widget update behavior. I need a TestStep sequence that verifies the name changes, the old value is preserved until refresh, and the final state matches the new config. Use CompareValue if that is the right fit.

That is stronger than “write a test” because it gives the skill a decision target, not just a topic.

provider-test-patterns skill FAQ

Is provider-test-patterns only for Terraform provider engineers?

Mostly yes. It is designed for Terraform provider acceptance tests and is most useful for provider-test-patterns for Backend Development, where you need reliable coverage around state, plan, and cleanup behavior.

Do I need to know terraform-plugin-testing already?

No, but the skill assumes you are working in that ecosystem. If you are new, the skill is still useful because it reduces guesswork around test structure, but you should expect to verify details against the referenced docs and your provider’s existing test conventions.

How is this different from a normal prompt?

A normal prompt may produce a plausible test file, but provider-test-patterns is more useful when the choice of assertion matters. It helps you decide whether to use ConfigStateChecks, a plan check, a destroy check, import state verification, or a sweeper pattern based on the test’s real purpose.

When should I not use it?

Do not use it for generic unit tests, unrelated Go testing, or quick syntax-only questions. It is also a poor fit if you are not using Terraform provider acceptance tests, because the patterns and constraints are specific to that workflow.

How to Improve provider-test-patterns skill

Give the missing test facts up front

The best way to improve provider-test-patterns results is to provide the smallest set of facts that change the test design:

• resource name and provider package
• whether the resource is created, updated, imported, or destroyed
• the exact attributes that must be checked
• whether values are static, computed, sensitive, or cross-step
• whether the test must cover cleanup or leak recovery

Mention the failure you are trying to prevent

If you say what can go wrong, the skill can choose better assertions. For example, tell it whether you are guarding against:

• drift after refresh
• incorrect import state
• values changing between steps
• missing destroy cleanup
• ephemeral data not being directly assertable

This is more useful than asking for a “complete example” because the test pattern depends on the failure mode.

Iterate by tightening assertions

After the first output, refine the request with the exact gap you still see. Good follow-ups include:

• “Make the ConfigStateChecks assert the computed ID format.”
• “Rewrite this as an import test with ImportStateKind.”
• “Add a sweeper and show the required TestMain setup.”
• “Convert this to an ephemeral-resource pattern using the echoprovider approach.”

That kind of iteration improves the provider-test-patterns guide output much more than asking for a longer version.