acceptance-test-patterns

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.

CheckExists / CheckDestroy for Autogen Resources

Autogen resources map directly from the OpenAPI spec and avoid typed Atlas SDK methods, calling the API through the SDK's untyped client instead. Their checkExists / checkDestroy should follow the same approach: verify against Atlas with an untyped client rather than a typed SDK method. Keep these check functions in the resource's own resource_test.go, since they are resource-specific. Issue the untyped request with the resource's version header (see the apiVersionHeader const in the resource’s resource.go). Promoting a preview API to stable then only requires bumping the version header, not a rewrite.

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)

1. 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.