Test Doubles — Stubs, Spies, and Mocks

1. Which of these collaborators are likely to make a test flaky (sometimes pass, sometimes fail without code changes)? (select all that apply)

• datetime.now() — the system clock

  Right. The clock changes every microsecond — any test that pins a specific date or time becomes a wall-clock dependency. That’s the canonical flaky-test recipe.

• An HTTP call to a third-party weather API

  Right. Third-party APIs go down, rate-limit, change their JSON shape, and time out. Every one of those failures is invisible from the test code itself.

• A function that reverses a list in memory

  In-memory list reversal is deterministic — same input, same output, every time. No flakiness. This is the kind of operation that can be tested with no double at all.

• A query against a remote database

  Right. Remote databases add latency, can be unavailable on CI, and their state can drift between test runs. Same flakiness risk as the HTTP call.

2. What is an indirect input to the System Under Test?

• Any input passed via keyword argument instead of positional

  The keyword/positional distinction is just Python syntax. Indirect input is about where the value comes from — the caller’s arguments versus a collaborator the SUT calls into.

• A value the SUT receives from a collaborator (rather than from the caller’s arguments)

  Right. The SUT’s direct inputs are its parameters; indirect inputs are values it gets by calling a collaborator. datetime.now() is the canonical indirect input — the SUT pulls it in, no caller passed it. Controlling indirect inputs is exactly what stubs are for.

• An argument that’s transformed before being used (e.g., str.lower())

  Transformation doesn’t change whether an input is direct or indirect. str.lower() operates on a value the caller passed in — still direct. Indirect inputs are pulled from collaborators behind the public signature.

• A global variable defined in another module

  Module-level globals can act as indirect inputs (since they aren’t part of the call signature), but they aren’t the defining example. The textbook indirect input is a value pulled from a collaborator’s method call — like clock.now().

3. (Spaced review — Testing Foundations) A test asserts result is not None after refactoring the SUT to accept a clock parameter. Is that a strong oracle?

• Yes — the test passes, so the refactor is verified

  Tests passing only tells you what their assertions held. is not None holds for any non-None value — including ones that violate the spec. Same Liar-test family from Testing Foundations Step 3.

• No — is not None is a weak oracle. It would pass for any non-None return, including False, [], or even a wrong date string. Pin the exact expected value with ==

  Right. is not None is the canonical weak oracle — it accepts any non-None return. Pair it with the seam refactor and the test still verifies almost nothing. Pin the exact expected value with == (or is True/is False for booleans).

• Yes — is not None is the recommended assertion for boolean-returning functions

  There’s no special rule for boolean-returning functions. The strong oracle for booleans is is True / is False — is not None is strictly weaker (it accepts True, False, and every other non-None value).

• It’s irrelevant — once you introduce a seam, oracle strength stops mattering

  Oracle strength matters in every test, regardless of whether you’re using a real collaborator or a double. A strong oracle paired with a stub is what makes a test simultaneously deterministic and meaningful. Doubles don’t replace strong oracles; they enable them.

4. Why is dependency injection the right move before introducing any test doubles?

• It’s a Python convention required by pytest

  Pytest doesn’t require dependency injection. The technique pre-dates pytest by decades. The reason to do it is design, not framework compliance.

• It creates the seam the doubles will use later. Without an injectable dependency, you can’t substitute a controlled version at test time

  Right. Dependency Injection (Meszaros) is the pattern that makes substitution possible. Once a collaborator is a parameter, any test can pass in a stub, spy, or mock. Without that seam, your only option is module-level patching — heavier and easier to get wrong.

• It improves runtime performance

  Performance is a non-issue at this scale. The benefit of DI is testability: the SUT becomes a unit you can isolate from its collaborators.

• It’s only needed when you’re using unittest.mock — for hand-rolled stubs you can patch globals instead

  Hand-rolled stubs use the same seam as unittest.mock doubles — both pass an object in at the parameter level (or replace it via patching). DI is universally useful regardless of which double-style you reach for.

1. Which best describes a Test Stub?

• A real implementation that’s been simplified for performance

  That’s closer to a Fake Object (Meszaros) — a working but lightweight implementation, like an in-memory database. A Stub doesn’t ‘work’ in the usual sense; it just returns the canned answer it was given.

• An object that answers questions with canned values — feeding controlled indirect inputs to the SUT

  Right. A Test Stub (Meszaros) provides controlled indirect inputs — it answers the SUT’s questions with values you chose, so the SUT’s behavior under those inputs is what gets tested.

• An object that records every method call so the test can verify them later

  That describes a Test Spy (Meszaros), the topic of Step 3. A spy adds call recording on top of stub-like behavior — but a stub on its own doesn’t track calls.

• An object that throws exceptions on every call to detect missing error handling

  That’s a specific use of a stub (the side_effect=ConnectionError pattern from Step 4), but it’s not the defining role. The defining role is providing canned answers; raising exceptions is just one kind of canned answer.

2. Why is hardcoded datetime.now() (used directly inside the SUT) not a stub?

• Because datetime.now() is a function, and a stub must be a class

  A stub doesn’t have to be a class — it just has to satisfy the contract the SUT expects. The defining property is control, not type. A function or a lambda can stub a function-shaped collaborator perfectly well.

• Because the test cannot control what datetime.now() returns. A stub is under the test’s control — the wall clock is not

  Right. The defining property of a stub is that the test controls what the stub returns. The wall clock changes every microsecond and is shared across processes — the test has zero control over it. That’s exactly why we replaced it with a FrozenClock.

• Because datetime.now() is too fast — stubs must add latency

  Latency is irrelevant to the stub vs not-stub distinction. Stubs are typically faster than the real thing because they skip work, but the defining property is control, not speed.

• Because Python’s standard library functions can’t be doubled

  Python’s standard library is no harder to double than your own code — datetime.datetime accepts a default override, modules can be patched, etc. The reason datetime.now() is the opposite of a stub is that the test can’t control what it returns; nothing about Python prohibits doubling it.

3. (Spaced review — Testing Foundations Step 3) A teammate writes:

assert service.daily_quest_title("u123") is not None

• Yes — the test passes, so the SUT must be returning the right title

  Tests passing only tells you the assertion held. is not None holds for any non-None value, including ones that violate the spec. The Liar test from Testing Foundations Step 3 still applies — being inside a stubbed test doesn’t make it stronger.

• No — is not None is a weak oracle. It accepts any non-None return — including the wrong title, an empty string, or False. Pin the exact value with ==

  Right. Stubbing collaborators makes the test deterministic; it doesn’t make weak oracles strong. is not None accepts wrong values just as readily as right ones. Pin the exact expected title with ==.

• Yes — is not None is the recommended assertion when stubbing dependencies

  There’s no special rule for assertions in stubbed tests. Stubs control inputs; oracles check outputs. The two are independent design dimensions, exactly as Testing Foundations Step 5 spelled out.

• It’s strong if the SUT’s return type is documented as a string

  Documentation doesn’t make is not None precise. The function returns one specific string per partition — pinning that exact string with == is the strong oracle. is not None is a structural assertion (“some object came back”), not a behavioral one (“the right object came back”).

4. When would a Fake Object (in-memory implementation) be a better choice than a Test Stub?

• When the test only needs to control one canned return value

  One canned answer is exactly what a Stub is for. A Fake’s added complexity (an in-memory store, mutating state) is overkill when you only need one return value.

• When the SUT calls the collaborator multiple times across a test sequence and expects different stateful answers each time (e.g., adding a quest, then fetching it back)

  Right. A Fake’s value is consistent stateful behavior across a test sequence. If the SUT does api.add_quest(...) then api.fetch_quests(...) and expects to see the added quest back, a Stub would have to be manually re-configured between calls — a Fake just works.

• When the test needs to verify that the SUT actually called the collaborator

  That’s a Spy or a Mock (Step 3 / Step 5), not a Fake. A Fake doesn’t track calls — it just behaves like a simplified version of the real collaborator.

• Whenever you’re testing a service class — Stubs are only for free functions

  Stub vs Fake has nothing to do with whether you’re testing a class or a function. The choice is about how much state the test needs the double to manage; the SUT’s shape is irrelevant.

5. Pick the right tool for the test. Your notify_user(user_id) function calls email_gateway.send(user_id, "Welcome") and returns nothing. The test must verify that the email was sent to user "u1" exactly once with the welcome subject. The real email_gateway.send actually delivers an email — you cannot run it in tests. Which test double is the right tool? (One choice from Step 1’s vocabulary table.)

• Stub — return a canned value to drive the SUT down a partition

  A stub returns canned inputs to drive the SUT. But here email_gateway.send doesn’t return anything that the SUT branches on — the SUT calls it for side effect, not for a return value. The test cares whether the call happened, which is a spy’s job.

• Spy — replace email_gateway.send and assert on the recorded calls afterward
• Fake — write a working in-memory email gateway

  A Fake is overkill — there’s no stateful behavior to simulate, just a single fire-and-forget call. Fakes are for SUTs that interact with the collaborator multiple times and expect consistent state (Step 2’s discussion of stubs vs. fakes).

• No double — just call the real email_gateway.send and check the inbox

  Hitting the real gateway breaks the test’s determinism (a real email is sent on every run) and slows the suite to a crawl. Tests must not have observable side effects on production systems.

def test_welcomes_new_user():
    spy = SpyEmailGateway()
    notify_user("u1", gateway=spy)
    assert spy.calls == [("u1", "Welcome")]

1. What is the defining role of a Test Spy that distinguishes it from a Test Stub?

• A spy is faster than a stub because it doesn’t compute return values

  Speed isn’t the distinction. Spies and stubs are both lightweight in-memory objects. The difference is what the test inspects after the SUT runs.

• A spy records every call made to it so the test can later inspect the recorded list. (A spy can also act as a stub by returning canned values, but the recording is what makes it a spy.)

  Right. A Test Spy (Meszaros) is a stub that also records calls. The test asserts on the recorded calls — that’s what enables verification of fire-and-forget collaborator interactions.

• A spy raises exceptions on every call to ensure error paths are exercised

  That’s a specific use of a stub or spy (set side_effect to an exception, as Step 4 will show). It’s not the defining property — it’s just one configurable behavior.

• A spy is a runtime debugging tool, not a test double

  Test spies are absolutely test doubles, not runtime tools. The terminology comes from xUnit Test Patterns (Meszaros, 2007). Don’t confuse “spy” in the testing sense with “spyware” in the security sense — they happen to share a metaphor but are unrelated concepts.

2. (Spaced review — Testing Foundations Step 3) A teammate asserts:

assert len(spy.calls) >= 0

• Yes — passing tests prove the SUT works

  Tests passing only tells you what their assertions held. len(any_list) >= 0 is a property of Python lists, not of the SUT — so passing this assertion proves nothing about the SUT’s behavior. Same Liar-test family as result is not None from Testing Foundations Step 3, ported to spy assertions.

• No — this is a structurally trivial assertion (len of any list is >= 0). It would pass even if the SUT never called the spy. Liar test.

  Right. The assertion holds for an empty list, a list of correct calls, a list of wrong calls — every list. The test passes regardless of behavior, which is the textbook Liar test. The fix: pin the exact expected call list with ==.

• Yes — len(...) >= 0 is the recommended starting assertion for spy-based tests

  There’s no such recommendation. Starting weak and “strengthening later” is how Liar tests get committed to main and forgotten. Always pin the exact expected call list from the start.

• No — but only because the assertion should use is True/is False instead

  is True/is False is for boolean returns. len(...) >= 0 would still be a Liar even if you wrote (len(...) >= 0) is True — the underlying expression is structurally trivial. The fix is to assert on the recorded calls themselves, not on len().

3. Which spy assertion is brittle (would break under a harmless internal refactor)?

• assert spy.calls == [("u1", 100)]

  This pins exactly the (user_id, gold) the spec mandates. If the SUT later changes how it formats internal log strings, this test still passes — because it doesn’t reference internal-state details. Goldilocks, not brittle.

• assert spy.calls == [("u1", 100, "2026-04-28T12:00:00Z", {"meta": "req-id-abc"})]

  Right. This pins a 4-tuple including a timestamp and a request-ID metadata dict — neither of which is in the spec for credit. If the SUT is later refactored to drop the metadata or change the timestamp format (without changing the user/gold contract), this test breaks for the wrong reason. Over-specified, brittle.

• assert ("u1", 100) in spy.calls

  in spy.calls is under-specified in the other direction (extra calls would still pass), but it isn’t brittle — it tolerates harmless changes. Brittle assertions break when the underlying contract is preserved; under-specified assertions miss bugs the contract was supposed to catch. Different problem.

• assert spy.calls[0] == ("u1", 100)

  Indexing [0] is just a way to access the first call. It pins what we want (user_id, gold) and ignores everything else. Not brittle. (Slightly less idiomatic than full-list equality, but not the over-specified case.)

4. (Spaced review — Step 2) Stub vs Spy in one sentence:

• A stub is hand-rolled; a spy uses unittest.mock

  Both can be hand-rolled or generated. Step 4 will show that unittest.mock generates either role from the same Mock class — the role isn’t determined by the library.

• A stub provides canned answers to the SUT’s questions; a spy records the SUT’s calls so the test can inspect them later

  Right. Stub = canned answers (control indirect input). Spy = record-and-inspect (verify indirect output). Same SUT/collaborator structure; different question being asked of the test.

• A stub is for read operations; a spy is for write operations

  Read/write isn’t the distinction — many real collaborators do both, and the choice of stub or spy depends on what the test wants to verify, not on whether the underlying call is a read or a write.

• A stub is faster than a spy

  Performance is a non-distinction. The choice between stub and spy is about what behavior the test verifies, not about how fast the double runs.

1.

api = Mock()
api.fetch_quests.return_value = [{"weekday": "Tuesday", "title": "..."}]

• Mock — because the variable name api and the class Mock are both used

  This is the most common confusion in Python testing. The class is Mock, but the role is determined by how the test uses the object — not by the class name. Here, api is configured to return a canned value; that’s a stub role.

• Stub — it answers fetch_quests(...) calls with a canned value, providing controlled indirect input to the SUT

  Right. return_value configures a canned answer; the SUT receives that answer as indirect input. Same role as StubQuestApiClient from Step 2 — just generated by Mock instead of declared as a class. (Yes, Mock also records calls, but here the test never asserts on them. The role is determined by the test’s intent.)

• Spy — every call to a Mock is automatically recorded

  Mock objects do auto-record calls, so the capability is there — but role is determined by what the test uses. This test only configures return_value and asserts on the SUT’s return value (state verification). No call assertions are made on api, so its spy capability is unused — it’s playing stub.

• Fake — it has a working in-memory implementation

  A Fake (Meszaros) has a working but lightweight implementation — typically with internal state (an in-memory dict, for example). Mock has no internal logic; it just returns whatever you configured. So this isn’t a Fake.

2. When should you reach for side_effect instead of return_value?

• Never — they’re interchangeable; pick whichever reads better

  They are not interchangeable. return_value always returns the same canned answer; side_effect lets the answer vary by call (or raise an exception, or be computed from arguments). Different behaviors, different test-design uses.

• When the collaborator should raise an exception (so you can test the SUT’s error-handling branch), or return different values across calls, or compute the return dynamically from the call’s arguments

  Right. side_effect covers three patterns return_value cannot: (1) raise on call → exercise the SUT’s except branch; (2) iterable → return different values on consecutive calls; (3) callable → compute return value from the args. Each one corresponds to a distinct test-design need.

• When you want the test to be slower (side_effect adds latency)

  Speed is a non-issue at this scale. The choice between return_value and side_effect is about behavioral capability, not performance.

• When return_value doesn’t exist on the version of unittest.mock you’re using

  Both have been in unittest.mock since at least Python 3.3. Versioning isn’t the reason to prefer one over the other.

3. A teammate writes:

ledger.credit.assrt_called_once_with("u1", 100)   # typo

• Mock corrected the typo internally and called the right assert method

  Mock has no auto-correct mechanism. It also has no idea you intended assert_called_once_with — to Mock, assrt_called_once_with is just another attribute name to auto-create.

• Mock auto-created assrt_called_once_with as a new mock method (because Mock creates attributes on access) — so the line just creates a new auto-mocked attribute and calls it. No actual assertion ran. The test silently passes regardless of behavior.

  Right. This is the typo trap — one of the most dangerous Mock pitfalls. Every attribute access on a vanilla Mock returns a new child Mock; calling .assrt_called_once_with(...) on that child Mock just records another call, returns a new Mock, and produces no assertion. Step 5 introduces autospec=True as one defense (it restricts attribute access to the real object’s interface).

• Mock raised an AttributeError and pytest caught it as a passing test

  There’s no AttributeError because Mock auto-creates attributes. That’s the whole problem — the failure mode is silent.

• Python’s interpreter detected the typo and warned via stderr

  Python doesn’t warn about typo’d method names — to the language, assrt_called_once_with is a perfectly valid attribute name. Static analyzers (mypy, pylint) might flag it; the runtime won’t.

4. (Spaced review — TDD) During the Red-Green-Refactor cycle, when do you typically introduce a Mock?

• Before Red — Mocks must exist before the test is written

  There’s nothing to mock until you write the test — and the test names which collaborators it needs to control. Setting up Mocks before the test exists is putting the cart before the horse.

• During Red — the failing test you write is the moment you decide which double to use, because the choice is part of the test design

  Right. The Red phase is where you design the test — including which collaborators to double and what role each should play. Green just makes the SUT pass; Refactor improves the code under a green safety net. The double choice is a Red-phase test-design decision.

• During Refactor only — Mocks are exclusively a code-cleanup tool

  Mocks aren’t a refactor-only tool. They’re a test-design tool that supports refactoring (by making behavior verifiable in isolation) — but the choice happens during Red.

• Never — TDD forbids Mocks

  TDD doesn’t forbid Mocks; it just emphasizes that the test drives design. Mocks are one of the design moves available — used judiciously when the SUT genuinely depends on collaborators.

5. Why is pytest’s monkeypatch fixture automatically restoring the original value an important property?

• It makes monkeypatch faster than unittest.mock

  Speed is irrelevant. The benefit is correctness across a test suite, not microseconds per test.

• Without auto-restore, a patched module attribute would leak into every subsequent test in the suite — silently breaking tests that don’t even know they’re using a patched value. Auto-restore makes the patch a test-local effect.

  Right. Test isolation is non-negotiable: a test that mutates global state and forgets to clean up corrupts every test that runs after it. monkeypatch (and unittest.mock.patch as a context manager / decorator) automate the cleanup, so you can’t forget.

• It’s a Python 3.11+ feature for memory management

  monkeypatch has been in pytest for many years; it’s not a Python 3.11 feature. And cleanup is a correctness concern, not a memory-management one.

• It’s only needed when you’re patching __builtins__

  monkeypatch can patch any attribute — module functions, class methods, instance attributes, dictionary entries. It’s not limited to __builtins__.

1. quest_service.py does:

from push_notifier import send_push

• patch("push_notifier.send_push") — patch where the function is defined

  Patches the binding in push_notifier’s namespace — but quest_service already has its own reference (created by the from ... import line). The SUT’s call ignores the patched binding and uses the local reference. Real function runs; mock is never called. Test fails (or worse, passes silently if no mock-call assertion).

• patch("quest_service.send_push") — patch where the SUT looks up the name

  Right. After from push_notifier import send_push, the name send_push is bound in quest_service’s namespace. The SUT’s send_push(...) call resolves there. Patching that exact namespace replaces the SUT’s reference — the patch intercepts.

• Either one works; both refer to the same function

  They refer to the same underlying function object but they are distinct namespace bindings. Patching one does not affect the other. This is the entire essence of the where-to-patch trap.

• Neither — from X import Y makes the function un-patchable

  It’s absolutely patchable — you just have to patch the right namespace. Python’s from ... import doesn’t disable patching; it just creates a binding the patch has to target precisely.

2. What does autospec=True primarily defend against?

• Typos in assert_* method names like assrt_called_once_with

  Half-myth. autospec constrains the Mock to the real object’s attributes; assert_* methods are part of Mock’s interface, not the real function’s. Whether autospec catches assrt_called_once_with depends on subtle interactions in different Python versions. The reliable typo defense is mypy/pylint.

• Calling the patched function with the wrong number or types of arguments — autospec enforces the real function’s signature, raising TypeError if you violate it

  Right. With autospec=True, the Mock’s __call__ enforces the patched function’s signature. mock_send("u1") for a function that needs (user_id, message) raises TypeError immediately. This catches signature-drift bugs that a loose Mock would silently accept.

• Slow tests — autospec speeds up Mock construction

  Autospec is slower than a loose Mock (it inspects the real object’s signature on construction). The benefit is correctness, not speed.

• Forgetting to call mock.reset_mock() between tests

  reset_mock and autospec are independent concerns. Autospec is about call signatures; reset_mock is about clearing recorded state between assertions.

3. What’s the relationship between Test Double (the umbrella name) and Stub / Spy / Mock / Fake / Dummy?

• Test Double is a synonym for Mock — they refer to the same kind of object

  Test Double is the umbrella (replaces the real thing — like a stunt double in a film); Mock Object is one specific role within that umbrella. Conflating them is exactly the colloquial confusion this tutorial fights.

• Test Double is the umbrella term (named after a stunt double in film); Dummy, Stub, Spy, Mock, and Fake are five specialized roles, each tagged for a different test-design need

  Right. Meszaros’ Test Double is the umbrella; the five named roles (Dummy, Stub, Spy, Mock, Fake) each address a different test-design problem.

• Test Double is just Meszaros’ branding — modern Python uses ‘mock’ to cover all of them

  Test Double pre-dates unittest.mock’s rise (Meszaros 2007). The umbrella isn’t a brand — it’s a stable, language-agnostic taxonomy used in Java/Mockito, JS/Jest, C#/Moq, Ruby/RSpec.

• Test Double is the umbrella, but it only includes Stub, Spy, and Mock — Fake and Dummy are unrelated patterns

  All five are subtypes of Test Double in Meszaros’ taxonomy. Fake (in-memory implementations) and Dummy (objects passed but never used) are explicit named patterns alongside Stub/Spy/Mock.

4. (Spaced review — Step 4) A Mock is patched in for the SUT’s collaborator. The test asserts mock.method.assert_called_once_with("u1", 100). What role is this Mock playing?

• Stub — the collaborator returns a Mock object

  Stub provides canned input to the SUT. This test isn’t using the Mock to feed an answer in — it’s verifying a call went out. Wrong direction.

• Spy — the test asserts on what the SUT did (the recorded call), inspecting after the fact

  Defensible. The assert_called_* style is post-execution inspection of recorded calls, which is closer to a Spy. (Some authors put assert_called_* cleanly in the Spy camp.)

• Mock Object — the test sets a strict expectation on the call

  Also defensible. The single-call expectation assert_called_once_with(...) IS a strict expectation on a specific interaction — Meszaros’ Mock Object territory. (Some authors put assert_called_* in the Mock Object camp.)

• Either Spy or Mock Object — the boundary depends on whether the expectation is configured up-front (Mock Object) or inspected after the fact via assert_called_* (Spy-leaning)

  Right. The line between Spy and Mock Object is fuzzier in unittest.mock than in Meszaros’ original taxonomy because the same Mock class can do either. The role boundary in unittest.mock runs through the Spy ↔ Mock Object axis, not through the class. Step 4’s lesson — “the role isn’t determined by the class” — applies again here.

5. (Spaced review — Steps 1 & 2) In Step 1 you injected clock=datetime.datetime as a constructor parameter (Dependency Injection). In this step you patched "quest_service.send_push" via unittest.mock.patch. When is each technique the right choice?

• DI is always preferred — patch() is only for legacy code you can’t modify

  DI isn’t always available. If the SUT calls send_push (a module-level function imported at the top of the file), there’s no parameter to inject — you’d have to reshape the SUT’s signature. patch() exists exactly for that situation.

• DI is the right choice when the SUT accepts the collaborator as a parameter you control; patch() is the right choice when the SUT imports a module-level name and you can’t reshape its signature without breaking other callers

  Right. DI is the cleaner default: parameter-level seams are explicit, easy to reason about, and don’t depend on Python’s import machinery. patch() is the heavier tool for module-level names — useful, but it brings the where-to-patch trap (this whole step) along for the ride. Reach for DI first; fall back to patch() when DI isn’t available.

• They’re interchangeable — pick based on how much typing each one takes

  They have different trade-offs. DI makes the seam visible in the SUT’s signature; patch() reaches into namespaces at runtime. The choice is structural, not stylistic.

• patch() is always preferred — DI requires more boilerplate

  DI requires the SUT to accept the collaborator as a parameter — that’s not boilerplate, it’s the seam being visible. patch() is the workaround for cases where DI can’t be used; preferring it universally is how teams end up with patch-strings scattered across their suites.

6. (Spaced review — Step 4 typo trap) What’s the most reliable defense against typos like mock.assrt_called_once_with(...) silently passing?

• Always use autospec=True

  Autospec primarily catches call-signature drift — wrong number/types of arguments to the patched callable. Whether it catches typos in assert_* methods is version-dependent and not reliable. Don’t lean on autospec for this.

• Run a static type checker (mypy / pyright) or linter (pylint) — it’ll flag the missing attribute on Mock. Pair that with code review.

  Right. mypy / pyright understand Mock’s typing and flag missing methods. pylint catches the typo statically. Code review catches what tooling misses. This combination is robust — autospec adds defense-in-depth but isn’t sufficient on its own.

• Memorize the spelling of every assert_* method

  Memorization is fragile and doesn’t help when you’re tired or rushed. Static tooling is what scales — let the computer remember the right spelling.

• Use Mock(spec_set=True) — it makes Mock immutable

  spec_set=True blocks setting new attributes (so m.foo = ... would fail). It doesn’t reliably block reading nonexistent attributes (so m.assrt_called_once_with(...) may still slip through depending on the spec). Use mypy/pyright.

1. A test mocks every internal helper of the SUT and asserts only on the mocks’ return values. Which antipattern is this?

• Behavior verification — the test checks how the SUT works

  This is over-mocking, not behavior verification. Behavior verification (Meszaros) is one call against an architectural-boundary collaborator — not every internal helper. Mocking internals couples the test to implementation choreography rather than to the spec.

• Over-mocking. The test verifies orchestration, not behavior. A pure refactor that renames or merges any internal helper breaks the test even though behavior is unchanged

  Right. Mocks should sit at architectural boundaries (HTTP, DB, clock, notifier) — not at every internal helper. Mocking internals creates brittle tests: any refactor that preserves behavior but rearranges helpers breaks the test for the wrong reason. Same lesson as Testing Foundations Step 4 (“behavior, not implementation”), in mock-shaped clothing.

• Solitary unit testing — the canonical and recommended style

  Solitary testing means “isolate the SUT from external collaborators (DBs, clocks, networks).” It does not mean “mock every internal helper.” Internal helpers belong to the SUT’s own module — mocking them is over-mocking. Solitary doesn’t endorse this.

• Liar test — the assertions don’t actually run

  Liar tests have weak oracles (is not None). The over-mocked test’s assertions ARE running and are technically strong (== against a canned value). The problem is what they assert about — implementation details, not the spec.

2. (Cumulative review) Match each scenario to the best single double:

• A: A pure function that adds two integers
• B: A function that calls datetime.now() to decide an expiration
• C: A function that POSTs to a payment gateway, fire-and-forget
• D: A function that round-trips with a Postgres user table 5 times

• A: stub, B: stub, C: mock, D: fake

  A is wrong. A pure integer-adding function has no collaborator — there’s no place to plug a stub. Doubling it is pure ceremony with no benefit.

• A: no_double, B: stub, C: mock (or spy), D: fake

  Right. A: pure function → no double. B: clock → stub. C: outbound call → mock or spy (interchangeable in unittest.mock). D: stateful round-trip → fake.

• A: mock, B: mock, C: mock, D: mock — all are mocks

  Conflating Mock the class with Mock the role. Pure functions don’t need any double; clock stubs return canned values (stub role), not strict expectations (mock role); stateful round-trips need fakes.

• A: spy, B: spy, C: spy, D: spy — spies are universally safe

  Spies record calls. A pure function doesn’t make outbound calls (nothing to record). A clock-dependency test wants to control input (stub), not observe output. Spy isn’t universally safe; it’s specifically for fire-and-forget output verification.

3. “Don’t mock what you don’t own.” What does this rule actually mean?

• Never use unittest.mock — only roll your own classes

  unittest.mock is fine — you can use it on objects you own. The rule is about what you mock, not which library you use.

• When you depend on a third-party library, wrap it in your own thin Adapter class first; then mock the Adapter, not the third-party. Your tests stay decoupled from the third-party’s internals

  Right. Wrap third-party libraries in your own Adapter (Adapter pattern) so your code depends on your type. Then mock that type. Benefits: tests don’t break when the third-party releases a new version; the mock surface is tiny and stable; you can swap the underlying library if needed. Hynek Schlawack’s essay “Don’t Mock What You Don’t Own” lays this out crisply.

• Only mock objects you instantiated yourself in the test

  Object-instance ownership isn’t the rule. The rule is about interface ownership — whose contract you’re depending on.

• Don’t share mocks between test files

  Sharing mocks across test files is its own concern (often a bad idea), but it’s unrelated to the “mock what you own” rule.

4. (Spaced review — TDD) During Red-Green-Refactor, when do you typically decide which double to use?

• Refactor — you start with real collaborators and double them later

  Refactor changes structure under a green safety net. Choosing a double mid-refactor would change what the test verifies, which violates the safety net principle.

• Red — choosing the double is part of test design, which happens when you write the failing test

  Right. Red is the test-design moment. The choice of stub vs spy vs mock vs fake vs no-double shapes both the test’s structure AND (often) the production design that emerges in Green. Choosing late means rewriting the test.

• Green — you add doubles when the test is red and you need to make it pass

  Green is just “make the failing test pass with the smallest code change.” Adding a double during Green would mean modifying the test, which corrupts the discipline (you’re chasing the test rather than letting it drive).

• It doesn’t matter which phase — doubles are an implementation detail

  It does matter. The double choice is a test-design decision that affects what the test verifies and how the production code is shaped. Treating it as an implementation detail leads to over-mocking and brittle suites.

5. (Spaced review — Step 3) Step 3’s test_complete_quest_LIAR_oracle was left in the file intentionally — assert len(spy.calls) >= 0 passes regardless of behavior, and Step 3 asked you to comment on it rather than fix it. Why keep a known-broken test in the file?

• It shouldn’t be kept — leaving broken tests in the suite is always wrong

  In a real production suite, you’d fix or delete it. In a teaching file, the Liar serves as a durable artifact — students return to the file and re-encounter the bad pattern alongside the good ones. That recognition skill is exactly what’s needed when reading a real codebase, where Liar tests are common.

• The Liar shape is recognizable; leaving it as a durable artifact trains the eye to spot the pattern in real codebases that are full of similar tests

  Right. Real-world codebases are full of Liar tests committed by tired engineers under deadline. The skill of spotting one on sight is what the Step 3 file builds. Pattern-recognition through durable bad-example artifacts is a deliberate pedagogical move — same family as showing students misspelled words alongside correct ones in language education.

• The Liar test technically passes, so it provides regression coverage for the SUT

  A test that always passes provides no regression coverage — that’s the entire definition of a Liar. The fact that it never goes red is the bug, not a feature.

• Refactoring it into a strong assertion would change what the test verifies

  True for that specific test (it would no longer be a Liar after refactor), but irrelevant to why we leave Liars in teaching files. The reason is pattern-recognition, not preservation of intent.

6. (Spaced review — Step 5) Why is autospec=True worth almost always reaching for when you patch a callable?

• It runs the patched function in a separate process for safety

  No process isolation involved. autospec is a runtime introspection of the patched object’s signature.

• It enforces the real callable’s signature on the Mock — so the moment a teammate’s refactor changes the production signature, the test’s calls to the mock raise TypeError immediately, instead of silently accepting drift

  Right. autospec is a design guardrail — “make the mock as strict as the real thing.” Signature drift is the most common refactoring bug; autospec catches it the moment the test runs. The cost is a few extra characters; the benefit is a real-world bug class entirely defended.

• It catches typos in assert_* method names reliably

  Half-myth. autospec primarily enforces call signatures, not assertion-method spelling. The reliable typo defense is mypy/pylint.

• It’s required by the Mock library — without it, patches don’t apply

  Patches work without autospec — they just don’t enforce signatures. autospec is a safety strict-mode, not a requirement.