Build fluency in the vocabulary of substituting a lightweight stand-in for a real dependency in a unit test.
0 / 5 completed
1 / 5
At standup, a dev mentions replacing a real dependency, like a payment gateway, with a lightweight stand-in object that mimics its interface during a unit test, so the test runs fast and doesn't depend on the real external system. What is this stand-in object called?
A test double is exactly this: a test double is a lightweight stand-in object, such as a mock, stub, or fake, that mimics a real dependency's interface during a unit test, so the test runs fast, deterministically, and without depending on the real external system, like an actual payment gateway. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This mimic-the-interface-without-the-real-system approach is exactly why test doubles let unit tests run in milliseconds instead of depending on slow or unreliable external services.
2 / 5
During a design review, the team replaces a real payment gateway with a test double in its unit tests, specifically because mimicking the gateway's interface without making a real network call keeps the test suite fast and independent of the gateway's uptime. Which capability does this provide?
A test double here provides fast, deterministic tests independent of external systems, since the test double responds instantly and predictably instead of depending on a real network call to an external service that might be slow, rate-limited, or down. Calling the real payment gateway directly in every test ties the test suite's speed and reliability to that gateway's own uptime and latency. This instant, predictable-response behavior is exactly why test doubles are standard practice for unit testing code with external dependencies.
3 / 5
In a code review, a dev notices a unit test for an order-processing function makes a real network call to the production payment gateway every time it runs, instead of substituting a test double that mimics the gateway's interface without the real call. What does this represent?
This is a missed test-double opportunity, since substituting a lightweight stand-in for the payment gateway would keep the test fast and independent of the gateway's uptime instead of depending on a real network call every run. A cache eviction policy is an unrelated concept about discarded cache entries. This real-network-call-in-tests pattern is exactly the kind of fragility a reviewer flags once a test suite needs to run reliably and quickly in CI.
4 / 5
An incident report shows a CI pipeline failed intermittently for weeks, because a unit test made a real network call to the production payment gateway, which occasionally throttled or rejected test traffic, instead of using a test double that never depended on the gateway at all. What practice would prevent this?
Substituting a test double for the payment gateway removes the dependency on the real gateway's availability or rate limits entirely. Continuing to make a real network call to the production payment gateway in every test run regardless of how often it gets throttled or rejected is exactly what caused the intermittent failures described in this incident. This test-double substitution is the standard fix once a test's reliability is found to depend on an external system's uptime.
5 / 5
During a PR review, a teammate asks why the team reaches for a test double instead of simply pointing every test at a real staging instance of the payment gateway, given that a staging instance is also not the production system. What is the reasoning?
A test double responds instantly and deterministically with no dependency on any external system at all, while a staging instance is more realistic but still introduces network latency, shared-state flakiness, and its own uptime as a dependency for the test suite. This is exactly why test doubles are preferred for fast, isolated unit tests, while a staging instance remains valuable for a smaller set of higher-level integration tests.