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

Answer to the Core Question

Which computed attributes can safely rely on generated placeholders, and which need explicit overrides?

• Deterministic computed attributes – values the provider derives purely from supplied inputs (e.g., a fully-qualified DNS name built from a record name and zone). These are safe to assert against generated placeholders, since any schema-valid value is acceptable.
• API-dependent computed attributes – values influenced by provider state, server-side defaults, quotas, or eventual consistency (e.g., API-assigned IDs, timestamps, chosen regions). These must be explicitly overridden in the mock_provider block with a fixed sentinel value so assertions are meaningful and stable.

How to detect when a mock passes schema validation but the real provider would reject the configuration?

1. Run the same test twice: once with mock_provider and once against the real provider in a sandbox or dedicated test account.
2. Capture the computed attribute values from both runs.
3. Automate a diff step that flags any mismatch. A mismatch indicates the mock placeholder does not reflect real provider behavior.
4. If the real provider rejects the apply (quota, permission, or API validation errors), capture the error and surface it in CI.

Strategy for a credible suite without credential-dependent steps

• Keep a two-tier structure:
  • Unit-style tests: use mock_provider for all resources; override only API-dependent attributes with sentinels.
  • Integration tests: a small curated set against the real provider with a minimal-permission test account, gated behind a separate CI job or manual trigger.
• Store expected computed values from the real provider as reference snapshots, and periodically re-run integration tests to detect provider default drift.
• For server defaults that change over time (timestamps, IDs), always override with a fixed value such as "0000-00-00T00:00:00Z" to avoid flaky assertions.

Practical Steps

1. Classify attributes – list computed attributes per resource and mark each as deterministic or API-dependent, based on provider documentation or observation.
2. Configure the mock – supply sentinels only where needed:

   mock_provider "example" {
     mock_resource "example_thing" {
       defaults = {
         id        = "sentinel-id"          # API-dependent
         fqdn      = "placeholder.example.com" # deterministic
       }
     }
   }
   

3. Write two assertion sets – schema compliance (type, requiredness) for everything; exact-value assertions only for deterministic attributes and sentinel values for API-dependent ones.
4. Add a comparison job – run the same configuration against the real provider, capture outputs, and diff against mock results:

   terraform test -var-file=real.tfvars
   terraform show -no-color > real_output.txt
   diff real_output.txt mock_output.txt
   

5. Review mismatches – any diff triggers manual review; update overrides or assertions accordingly.

Assumptions and Caveats

This guidance assumes Terraform 1.6+ where terraform test and mock_provider are available. Mocks cannot simulate quotas, permission checks, or eventual consistency, so mock-only suites will always carry residual risk. One detail that would refine this answer: the specific computed attributes of your provider and any documented server-side defaults, which determine the deterministic vs. API-dependent split.