Stub
A fake that just hands back a canned answer so the test can carry on. It never checks who called it or how often.
See it
What it is
A stub replaces a collaborator with something that hands back a fixed answer and asks no questions. No call counts, no argument checks, no verification of any kind: it exists so the code under test can keep going. Typical shapes are a vi.spyOn on the client that resolves a fixed user, a sinon.stub that returns 42, or an MSW handler that always answers with the same JSON. You then assert on the result your code produced, which is state verification.
Stubs shine on branches you cannot reach otherwise, and error paths are the best example. Stub the payment call to throw a 500 and assert your code retries; stub the feature flag to false and assert the old UI renders; stub the clock to a Tuesday and assert the weekend banner stays hidden. Reaching those states with the real dependency is usually impossible.
The failure mode is drift. Your stub keeps returning last year's payload shape while the real API renamed a field, and the suite stays green over a broken app. Generate stub data from the same types or schema the client uses, refresh it from recorded real responses, and keep at least one test hitting the live thing. Separately, watch the word: outside testing a 'stub' also means an empty placeholder function waiting to be implemented.
Ask AI for it
Stub the external calls in these tests so I can drive every branch. For each dependency, replace the real call with one that resolves a fixed payload built from the same TypeScript types the production client uses, and add variants that reject with a 500, a 404, and a timeout so the retry and fallback paths get covered. Keep the stubs dumb: no call assertions, just canned returns, with the assertions on the value the function under test produces. Restore all stubs in afterEach so nothing leaks between tests.