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

# Testing Your Adapters

> Build repeatable tests for the request path, service behavior and target environment.

Test the adapter with the same operations, request options and failure cases your application depends on. A useful test proves more than endpoint reachability: it checks the origin-facing response, the resulting target state and the behavior your application observes when something goes wrong.

## Start with an operation inventory

List each origin API operation the application calls, including request options that affect behavior. Include background jobs, administrative tools and infrastructure automation, not only the main request path.

For each operation, record:

* the expected success response;
* the target resource or state change;
* relevant naming, pagination, ordering and consistency behavior;
* authorization failures and invalid-input errors;
* retry and idempotency expectations;
* tuning directives the request or resource uses.

Use the selected service mapping as the contract for this inventory.

## Test in layers

| Test layer                                                          | Purpose                                                                                       |
| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| Origin client against an origin emulator                            | Verify how the application constructs requests and handles origin API responses.              |
| Application through Cloud Adapter to a target emulator              | Exercise translation with controlled, repeatable backend state.                               |
| Application through Cloud Adapter to an isolated target-cloud scope | Verify target identity, networking, quotas, lifecycle behavior and managed-service semantics. |
| Representative workload through the deployed adapter                | Measure the complete request path under expected concurrency and data volume.                 |

Use [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) for fast local feedback. Keep a bounded target-cloud test for behavior that depends on the managed service or its environment.

## Build a bounded lifecycle test

1. Create uniquely named test resources using dedicated credentials.
2. Read the resource through the origin API and compare important fields with target state.
3. Update the fields and tags your application uses, then read them again.
4. Exercise listing, filtering or pagination when the application depends on them.
5. Delete the resource and verify both the origin-facing response and target state.
6. Clean up only resources created by the test.

Keep the same lifecycle available as a smoke test after configuration changes and adapter upgrades.

## Exercise failures deliberately

Include a missing resource, invalid input and denied action. Test a timeout or interrupted connection for write operations, then inspect target state before retrying. A failed or missing response does not prove that the backend performed no work.

Use [diagnostic response headers](/cloud-adapter/debugging/response-headers), request identifiers and backend evidence to separate client, adapter, network, identity and target-service failures.

## Preserve useful evidence

For every run, record the adapter version, selected mapping, redacted configuration, target region, operation, response status, diagnostic headers and resulting target state. Preserve enough detail to reproduce the request without retaining credentials or production data.

When behavior differs from the origin service, turn the case into a regression test before changing configuration or tuning. See [debugging](/cloud-adapter/debugging/overview) for the investigation workflow.