Across a large test suite, when would you invest in writing and maintaining a hand-rolled in-memory implementation of a collaborator such as a repository, instead of configuring Mockito mocks in each test that needs it?

## The decision, framed Both options replace a collaborator: a Mockito mock configured per test, or a small hand-written class implementing the same interface over an in-memory data structure. This is an investment question — the second carries up-front and ongoing cost that pays back only at a certain scale of use. ## Signals favouring the hand-written implementation **Repetition across the suite.** When the same three or four stubbings appear in dozens of test classes, that setup is shared code that happens to be copied. Any change to the interface, or to what "not found" means, forces a sweep across all of them. One implementation centralises it. **Stateful scenarios.** Mockito is call-oriented: each stubbing answers one call. Tests needing continuity — save then load, insert twice and expect a uniqueness failure, delete then verify absence, paginate over what was written — must script every step and quickly become unreadable. An in-memory map gives continuity for free, and the test reads as a story about behaviour rather than about calls. **Rules leaking into stubbings.** If every test must remember "returns empty for soft-deleted rows", that rule now lives in fifty places. A single implementation holds it once, and changing it updates the whole suite. **Readability of higher-level tests.** Tests exercising several services together become nearly unwritable with mocks, because each service's calls must be anticipated. A shared in-memory implementation lets them state a scenario and assert an outcome. ## Signals favouring mocks **Low usage.** A collaborator touched by three tests does not justify a maintained class. **Interaction is the assertion.** When the point is "the gateway was charged exactly once" or "no mail was sent", a mock gives verification directly; a hand-written stand-in would need its own call recording, which is re-implementing Mockito. **One-off edge cases.** Timeouts, exotic exceptions, a call returning garbage: stubbing one call is far cheaper than teaching an implementation to misbehave on demand. **Wide or unstable interfaces.** Implementing a thirty-method interface, or one still in flux, is a maintenance tax — and a hint the interface should be split. ## The real risk: divergence The strongest argument against a hand-written stand-in is fidelity. An in-memory repository has no unique constraints, no cascades, no lazy loading, no transaction rollback, no collation rules and no optimistic-locking conflicts. A suite running entirely on it can be uniformly green while the real database rejects half the writes — and unlike a mock, its plausibility invites over-trust. Three mitigations. Keep the interface narrow and domain-shaped, so there is little semantics to reproduce. Write one contract test suite — behavioural tests written against the interface — and run it against both the in-memory and the real implementation, so drift fails a test rather than production. And keep a thin layer of real integration tests for the persistence-specific behaviour that no in-process substitute can honestly reproduce. ## Phasing the investment Start with mocks. When a collaborator crosses roughly a dozen test classes, or the first stateful scenario becomes painful, extract the implementation and migrate opportunistically: new tests use it, old ones move when touched. Treat it as production-quality code — reviewed, small, owned by whoever owns the interface. If it starts growing conditionals to satisfy individual tests, that is the signal it has become a mock with worse ergonomics and should be split or retired. ## What the answer should convey There is no universal winner. Mocks are cheap per test and expensive per suite; a maintained in-memory implementation is expensive once and cheap thereafter, provided its fidelity is actively defended. The judgement turns on scale of reuse, statefulness of the scenarios, and how much of the real collaborator's semantics the tests genuinely depend on.