test-doubles-choice

Choose based on what the test verifies: stubs return canned data for state verification, fakes provide working lightweight implementations, spies record calls for interaction assertions, and strict mocks enforce must-not-happen requirements. Stubs are the default choice.

A stub returns canned data so the test can verify state, while a strict mock fails on unexpected calls and verifies interactions. Stubs survive refactors because they assert on outcomes; mocks weld tests to implementation details and break on internal renames.

Use a fake, such as an in-memory repository or SQLite standing in for Postgres, when many tests need realistic behavior like querying or uniqueness checks. One fake replaces dozens of per-test stub setups, but it needs contract tests against the real implementation.

Tests break on renames when they mock private functions or assert on internal call sequences instead of state. Fix this by extracting pure logic, doubling owned boundary interfaces, and asserting on outcomes rather than collaborator calls.

No. Wrap the vendor SDK in a thin adapter your team owns and double the adapter instead. Mocking a 40-method vendor client means vendor API churn breaks hundreds of tests, while an adapter confines breakage to one place.

Skip the double when extracting pure logic from the I/O call lets you test the logic directly, or when testing through the real dependency is the right move. The best double is no double; integration-test-strategy covers testing through real dependencies.