Test Doubles

A test double replaces a component that an application would normally use, such as an HTTP API, database client, payment provider, or message publisher. The replacement provides controlled behavior so a test can exercise a specific scenario. For cloud applications, this is particularly useful when dependencies incur charges, enforce rate limits, contain sensitive data, or perform irreversible actions such as sending notifications or charging a card.

Test double is an umbrella term, not a synonym for one implementation technique. A stub returns predefined responses. A mock checks expected interactions, such as whether a payment request contains the correct idempotency key. A spy records calls for later inspection. A fake provides a working but simplified implementation, such as an in-memory repository. A dummy satisfies a required parameter without participating in the scenario. Testing libraries sometimes use these labels differently, so define what behavior each replacement provides.

Make dependencies replaceable through interfaces, constructor parameters, client factories, or configurable endpoint URLs. For example, an order service can receive a payment client rather than constructing a production client inside its business logic. A unit test can inject a stub client that returns a declined payment. An integration test can run the actual order handler, serialization code, and HTTP client while directing payment requests to a mock HTTP server. That test exercises the application's integration with the substitute, not its compatibility with the real payment provider.

In a cloud development environment, a mock API can expose representative HTTP methods, paths, status codes, headers, and response bodies. Amazon API Gateway REST APIs support mock integrations that return configured responses without calling a backend. A dedicated mock server running in a container is more suitable when scenarios require stateful behavior, deliberate delays, connection failures, or complex request matching. Keep mock endpoint configuration separate from production configuration, and prevent tests from falling back to production endpoints when configuration is missing.

Test more than successful responses. A payment integration should handle validation failures, authorization errors, throttling, malformed responses, and transient server errors. Configure response sequences to verify retry limits and backoff behavior. Simulate a timeout after a payment has been accepted to check that retries reuse the same idempotency key. For asynchronous workflows, verify how the application handles duplicate messages and out-of-order delivery where the real system permits them. Reset fake state and recorded requests between tests so parallel runs do not interfere.

The main trade-off is fidelity versus speed and control. An in-process stub is inexpensive and deterministic, but bypasses networking and serialization. A remote mock API exercises more of the request path, but introduces deployment overhead and may still omit authentication, service limits, consistency behavior, and infrastructure permissions. Replacing an SDK method does not prove that the deployed application has the correct IAM permissions or network access.

Keep doubles aligned with documented contracts and representative, sanitized examples. Contract tests can detect disagreements about request and response formats; where practical, verify those contracts against the provider. Maintain a smaller set of integration or end-to-end tests against isolated real resources or an external provider's sandbox. Passing tests against doubles establishes behavior under the modeled conditions, not complete production compatibility. In development and deployment pipelines, use doubles for repeatable scenario coverage and real integrations for the boundaries that substitutes cannot validate.