> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# High Fidelity Cloud Emulators

> Test supported API behavior locally, then verify cloud-specific behavior against the real backend.

High-fidelity emulators help exercise cloud API behavior with local resources and controlled test state. They are useful for SDK compatibility checks, repeatable failures and debugging without using production data.

High fidelity applies to the APIs and behaviors the emulator implements. It is not a claim that every cloud service, quota or failure mode is reproduced.

## Choose what the test exercises

There are two useful arrangements:

| Arrangement                                                                      | What it checks                                                                       |
| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Application calls an emulator implementing the origin API.                       | Application use of the covered API without cross-cloud translation.                  |
| Application calls an adapter whose backend endpoint is a target-native emulator. | The adapter's translation path for the covered origin operation and target behavior. |

The first arrangement does not prove the second. Record which path you tested, including the exact emulator, adapter version, backend selection and endpoint. A local URL in one setting is insufficient evidence that every backend request stays local.

## Build a repeatable test

1. Use dedicated test configuration and credentials with no access to production resources.
2. Start the required local services and verify readiness before sending requests.
3. Configure the application and adapter endpoints explicitly. Confirm the expected target receives the request.
4. Create uniquely named test resources and exercise create, read, update and delete operations your application needs.
5. Verify outcomes, collect errors and response identifiers, then clean up only those resources.
6. Repeat from known state to detect dependence on leftover data.

Keep the resource setup with the test. For a tuning regression, preserve both the initial tags and any later supported tag updates. Resetting a process is not necessarily resetting its persistent database or object store.

## Test failures as well as success

Include a missing resource, invalid input and a denied action where the emulator supports that behavior. Exercise an interrupted connection and inspect possible effects before retrying a write. A synthetic failure does not establish the target cloud's actual retry or throttling behavior.

For automated tests, use isolated resource names, bounded timeouts and explicit cleanup. A test suite should not wait indefinitely for a container or local service that failed to start.

## Verify against the real target

Use a dedicated cloud test scope to validate permissions, credential refresh, network access, regions, quotas, consistency and resource lifecycle behavior. Measure latency and throughput there under the conditions you intend to operate.

Keep the local test for fast regression feedback and the cloud test for behaviors a local emulator cannot establish. Report which environment produced each result when [debugging](/cloud-adapter/debugging/overview).

## What local evidence means

| Evidence                            | Establishes                                                        | Does not establish                                              |
| ----------------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------- |
| Origin client against an emulator   | Client request construction and covered origin behavior            | Translation to a target backend                                 |
| Adapter against a target emulator   | Translation for the implemented operation and emulator behavior    | Real-cloud IAM, quota, latency or managed-service failure modes |
| Adapter against a real test backend | The tested identity, region, resource and operation under that run | Unused operations or a different direction                      |

Keep these evidence classes separate in test reports. “Works locally” is useful regression evidence, not a production compatibility claim.