| name | acceptance-test-patterns |
| description | Best practices for writing and organizing acceptance tests in this Terraform provider. Use when creating new acceptance tests, modifying existing tests, fixing flaky tests, or reviewing test code. Covers test consolidation, avoiding duplicates, plural data source ordering, and plan-only validation tests. |
Acceptance Test Patterns
Test Consolidation
Combine Resource + Data Source Basic Tests
Merge basic tests for a resource, its singular data source, and its plural data source into a single test function in resource_test.go. This reduces CI time by avoiding repeated terraform init/plan/apply cycles for the same infrastructure.
Eliminate Duplicate Tests
Before adding a test, verify no existing test already covers the same configuration and assertions. Tests with identical configs and checks waste CI time.
Plural Data Source Ordering
Avoid hardcoded indices (e.g., results.0) when asserting on plural data source results unless the parent resource is guaranteed to be unique within the test execution. When uniqueness is ensured, using results.0 is acceptable. Otherwise, the API may return items in any order and the test resource may not be at a predictable index.
Preferred approach (when index is not safe)
PluralResultCheck helper — dynamically finds the test resource by name before asserting on its attributes.
Plan-Only Tests for Validation
Use PlanOnly: true with ExpectError for tests that validate schema-level constraints (e.g., discriminator validation, required attribute enforcement). These are fast because they don't require real infrastructure.
resource.TestStep{
Config: configWithMissingRequiredField,
PlanOnly: true,
ExpectError: regexp.MustCompile(`expected error message`),
}
Test Grouping in CI
- Autogenerated resource tests that run faster belong in the
autogen_fast CI group.
- If a prod autogenerated resource's tests take significantly longer than the
autogen_fast average, evaluate moving it to a separate test group.
