Terraform test framework mock_provider vs provider plugin: computed attribute fidelity boundary

Integration boundary

The native terraform test framework with mock_provider blocks enables plan and apply assertions without production credentials by satisfying provider schemas with generated or overridden values. This creates an integration boundary between Terraform core's test harness and the provider plugin's actual runtime behavior.

Constraint

Mocked resources return computed attributes as placeholder values unless explicitly overridden in the mock block. Schema validation is enforced, but provider-side API constraints — quotas, eventual consistency windows, server-side defaults, and permission checks — are not simulated. A test that passes with mocks may still fail against the real provider when computed values diverge or API-level validation rejects the request.

Goal

Determine how to structure test assertions so that mocked computed attributes meaningfully approximate real provider output, without relying on provider-specific endpoint overrides or local emulators.

Which computed attribute patterns are safe to assert against generated placeholders versus requiring explicit overrides? How can test authors detect when a mock's schema-level validation passes but the real provider would reject the same configuration at apply time? What strategy keeps the test suite credible without introducing credential-dependent steps?