// 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.
| 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. |
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.
Before adding a test, verify no existing test already covers the same configuration and assertions. Tests with identical configs and checks waste CI time.
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.
PluralResultCheck helper — dynamically finds the test resource by name before asserting on its attributes.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`),
}
autogen_fast CI group.autogen_fast average, evaluate moving it to a separate test group.Summarize a GitHub Actions test suite run for the mongodb/terraform-provider-mongodbatlas repo — fetches job logs, classifies failures, and produces a Slack summary led by an explicit code-regression verdict. Use when the user shares a workflow run URL or run_id, or when triggered by the test-suite webhook to decide whether on-call should investigate.
Standards for pull requests, documentation, and code review in this Terraform provider. Use when creating PRs, writing or editing documentation (schema descriptions, docs markdown, examples), reviewing code, or adding changelog entries. Covers PR structure, docs style guide, example conventions, and changelog practices.
Best practices for developing Terraform resources and data sources in this provider. Use when creating new resources, modifying schema definitions, implementing CRUD operations, handling state transitions, or working with autogenerated resources.