Use provider doubles without mistaking them for integration tests

A fake email provider returning success makes a notification test fast and predictable. It does not establish that the real provider accepts the request, that credentials are valid, or that an email reaches its destination. Provider doubles are useful when their scope is stated honestly. Confusion begins when a passing fake is described as an integration test of the remote boundary.

Consider an illustrative application that stores a support request and sends a confirmation through an external provider. The application should persist the request, classify delivery outcomes, and offer an understandable recovery path. A double can exercise those branches without sending messages to real people. Separate evidence is needed for the provider adapter and operational configuration.

Name the contract being substituted

Define the application's provider interface in domain terms, such as send confirmation with recipient, template data, and operation identity. Specify possible results: accepted, rejected permanently, unavailable temporarily, or uncertain after timeout. Avoid an interface that can return only success, because it cannot support meaningful failure tests.

A practical artifact lists input fields, result categories, side effects, and guarantees not covered by the double. State that a fake accepted result means the application received that category, not that the provider delivered anything. Keep the distinction visible in test names and reports. This contract also makes it easier to change providers without letting vendor-specific details spread through every route and test fixture.

Build behavioral doubles rather than convenient stubs

Make the double configurable for relevant outcomes. It can record safe call metadata and return accepted, permanent rejection, transient failure, or a delayed result. Use synthetic destinations and payloads. Do not copy production messages containing private data into fixtures.

Keep the double small. It need not recreate the provider's entire service, but it should enforce the application contract's required fields so obviously malformed input cannot pass unnoticed. Avoid implementing the same business decision inside the fake and production path; that can make both agree on the same defect. Tests should assert application state and user response under each provider outcome, with call recording used only where it supports the actual contract.

Test local persistence and partial outcomes

For support-request creation, verify that a provider failure does not erase an already accepted durable request unless the product contract explicitly requires all-or-nothing behavior. The UI should distinguish saved request from failed confirmation delivery. A timeout may leave delivery uncertain, so avoid telling the user that nothing happened when the provider might have accepted it.

Inspect retry identity and job state if delivery is deferred. A double can verify that retries preserve the same business operation key and update the correct record. It cannot establish the provider's idempotency semantics. See third-party failure handling for separating local success from remote delivery. This is one of the strongest uses of doubles: exercising application recovery decisions without depending on a live outage.

Verify the real adapter separately

Use provider documentation and a safe integration environment to check request formatting, authentication, supported fields, status mapping, and timeout behavior. Where a sandbox is available, use synthetic destinations and bounded requests. Do not assume a sandbox exactly reproduces production delivery or quotas; record its scope.

Test the adapter's parsing with representative documented responses, then exercise at least the supported real connection boundary where authorized and practical. Check whether unexpected response shapes fail safely. A double that returns the application's final result category bypasses this translation, so adapter tests are essential. Keep installed client-library versions explicit and verify proposed methods against official documentation rather than generated guesses.

Avoid tests that merely repeat the implementation

A weak test verifies that send was called because the implementation calls send. A stronger test verifies that accepted delivery produces the correct state, a permanent rejection is not retried indefinitely, and a transient failure remains recoverable. The call can be part of the evidence, but it should not be the whole claim.

Do not assert every private argument arrangement if the externally meaningful contract is smaller. Excessive mock expectations make refactoring difficult while still missing outcome errors. Conversely, important fields such as recipient scope and operation identity deserve explicit checks. Choose assertions from the business behavior and boundary risk. The fake's convenience should not decide what the application is expected to guarantee.

Include an uncertain outcome in the double when the application must handle it. A timeout can occur after the provider accepts a request, so modeling every timeout as definite rejection encourages unsafe retries. The application test should preserve an unresolved delivery state or use a verified idempotent retry contract. This case is distinct from a connection failure known to occur before submission and deserves its own expected behavior.

Keep test reports precise

Label tests by their boundary: application test with provider double, adapter contract test, or provider sandbox integration. State which credentials and environment were used without revealing values. If a live check could not run, record it as not run rather than treating the fake result as a substitute.

Avoid phrases such as email delivery verified when only provider acceptance was observed. Delivery, inbox placement, and human reading are different events. A report can accurately say that the provider accepted a synthetic request and that the application handled its response. Precise wording prevents downstream reviewers or assistants from strengthening the claim unintentionally. It also makes failures easier to route to application, adapter, or provider ownership.

Account for drift and operational configuration

Provider contracts and SDKs can change. Revisit adapter checks when versions, authentication, templates, or required fields change. Keep the double aligned with the application's supported categories, but do not silently change it to make new code pass. Review whether the contract itself changed.

Runtime configuration needs its own validation and controlled verification. A correct adapter with an expired credential still fails in deployment. A sandbox key used in production may produce misleading behavior. Connect those checks to configuration management and deployment evidence. Doubles reduce test dependence on remote systems; they do not remove the need to operate those systems correctly.

Use AI to challenge the boundary claim

Give an assistant the provider interface, double, adapter, and test names. Ask what each test proves and which remote assumptions remain unverified. Require it to identify cases where the fake bypasses parsing, authentication, or network behavior. This is more useful than asking it to generate a large set of success-path mocks.

Have it propose a small failure matrix and a separate safe integration plan. Verify any vendor-specific suggestions against primary documentation. AI can help improve test scope and reporting, but it should not infer real delivery from a local double. The final evidence should preserve the distinction between controlled application behavior and the external boundary that still needs separate verification.

Sources

Node test runner documentation provides a primary reference for mocking and asynchronous tests.

Playwright testing best practices discuss testing controlled application behavior and external dependencies. The support-request double is illustrative.