[[Test double]]s are used in tests of system components that integrate with other services/components in order to address several of the [[Integration testing#Criticisms of integration tests|criticisms of integration tests]]. They can help to: - minimise/eliminate test setup time (e.g. provisioning infrastructure dependencies) - increase test execution speed - reduce the fragility of the test suite However, fundamentally they are a "double"—a substitute for the real thing—and so any behaviours attributed to them in the test code by way of setting mock expectations or fake/stub implementations are not guaranteed to be 100% accurate. Such inaccuracies can take several forms: - An assumed behaviour is simply incorrect (e.g. a casing mismatch in a payload field passed to the "double") - An assumed behaviour is incomplete and doesn't take into account certain edge cases - An assumed behaviour was once correct but now the real service behaves slightly differently ## Test doubles in integration tests Consider a system that follows a microservices architecture and within this system there is a Provider service and a Consumer service. Using test doubles in this context would involve mocking the Provider responses (when writing tests for the Consumer) or simulating the Consumer requests (when writing tests for the Provider). The big problem with this approach is that it does not give us the confidence to release as there is nothing to ensure that the simulated requests/responses behave the same way as the real ones. #TODO: - Give more specific examples of failure modes that Test doubles will not catch - Provide a concrete example of this issue applied to a mocked out serverless use case (async data flow)