5 exercises on the vocabulary of test doubles — mocks, stubs, spies and fakes, fixtures, set-up and tear-down, and isolating a unit.
Key patterns
mock a dependency → replace it with a double
stub a response → return canned data
spy → record how a call was made
set up / tear down → before/after hooks
fixture → known starting data; isolate a unit
0 / 5 completed
1 / 5
A developer explains a unit test: "The real payment gateway is slow and costs money, so we ___ it and return a canned response instead." Which verb is the standard collocation?
Mock a dependency — the core unit-testing verb:
To mock something is to replace a real dependency with a controlled stand-in (a "double") so the unit under test runs fast, deterministically and offline.
"mock a dependency" / "mock the API" / "mock out the database"
"mock the network call so the test doesn’t hit a real server"
noun: "a mock", "set up a mock"
tools: Jest mocks, Mockito, unittest.mock
Why not the others? "Fake" is a real noun in testing (see later) but as a verb here it’s vague; "copy" and "wrap" describe different operations entirely. The precise, idiomatic verb for substituting a dependency in a test is mock.
2 / 5
A tester distinguishes two test doubles: "A ___ just returns hard-coded data; a ___ also records how it was called so you can assert on the interaction." Which pair is correct?
Stub vs spy — the test-double family:
The classic taxonomy (Gerard Meszaros / Martin Fowler) distinguishes four doubles:
Stub — returns canned / hard-coded responses; "stub a response", "stub out the call". No verification.
Spy — like a stub but also records how it was called (arguments, call count) so you can assert afterwards.
Mock — pre-programmed with expectations; it fails the test if it isn’t called as expected.
Fake — a working lightweight implementation (e.g. an in-memory database) — real logic, not production-grade.
Collocations: "stub a response", "set up a spy", "a fake repository", "the mock expects one call". In everyday speech developers loosely say "mock" for all of these, but in precise usage a stub supplies data and a spy records the interaction.
3 / 5
A test file has methods that run automatically before and after each test. A developer says: "Use ___ to open a fresh database connection, and ___ to close it and clean up." Which pair completes the sentence?
Set up / tear down — the test lifecycle collocation:
Most test frameworks provide hooks that run around each test (or each suite) to prepare and clean up shared state:
set up (verb) / setup (noun) — create the world the test needs: open connections, seed data, build objects. "the setup step", "set up the fixtures".
tear down (verb) / teardown (noun) — undo it: close connections, delete temp files, reset globals.
Framework names for these hooks:beforeEach/afterEach (Jest, Mocha), setUp/tearDown (xUnit, JUnit, Python unittest), fixtures with yield (pytest).
Why it matters: proper teardown keeps tests isolated — one test’s leftover state must not leak into the next, or you get order-dependent, flaky tests. "Set up" and "tear down" are the fixed idioms; "open/close" describes resources, not the test lifecycle itself.
4 / 5
A QA engineer says: "This test uses a JSON ___ — a known sample file of input data we load so every run starts from the same state." Which term is correct?
Fixture — the known starting data for a test:
A fixture is the fixed baseline a test runs against: sample records, a prepared file, or a configured object graph that puts the system into a known state before the test executes.
Contrast the distractors: a mock replaces a dependency (behaviour), a stub returns canned responses, and an assertion is the check at the end. A fixture is the data/state you start from — not a substitute for collaborators and not a verification. The shared idea across all of them is making the test deterministic and isolated.
5 / 5
Explaining why a class is hard to test, a developer says: "It calls the network and reads the clock directly, so we can’t ___ the unit — its behaviour depends on the outside world."
Isolate a unit — the goal that drives all test doubles:
To isolate a unit means to test one piece of code on its own, with its real collaborators replaced by doubles, so the result depends only on the code under test — not the network, the clock, the filesystem or another team’s service.
"isolate the unit under test"
"tests should be isolated from each other and from external systems"
"in isolation" — "test the parser in isolation"
How you achieve isolation: mock the network, stub responses, fake the database, inject the clock — everything in this set serves this one aim. Code that reads the clock or calls the network directly is hard to isolate because it has hidden dependencies; dependency injection makes those seams visible so they can be replaced in a test. Isolation is what keeps unit tests fast, deterministic and free of flakiness.