DI as a testing seam: fakes, mocks, and the boundary that matters

A team is proud of their OrderService test suite: 100% coverage, every dependency mocked, all green. Then a refactor that changes nothing about behavior — splitting one repository method into two — turns forty tests red. The tests were not checking that orders get placed. They were checking that repo.save was called exactly once with exactly these arguments. The seam DI gave them was real; they just pointed it at the wrong thing.

The seam is the payoff

Everything in this unit — constructor injection, the composition root, abstractions instead of new — pays off here. Because OrderService receives a PaymentGateway rather than constructing a StripeClient, a test can pass in a substitute. That substitute is a test double, and the injection point is the seam: the join where production wiring is swapped for test wiring. No seam, no isolated unit test. This is why “is it testable?” and “are the dependencies injected?” are nearly the same question.

Two doubles, opposite purposes

The word “mock” is used loosely for every substitute, but the distinction is the whole lesson:

• A stub / fake stands in for a dependency and provides state. A fake UserRepository backed by an in-memory Map behaves like the real thing: you save a user, you can read it back. Your assertions check the result — the order ended up persisted, the returned total is correct.
• A mock is programmed with expectations about calls. It asserts that payment.charge(amount) was called once with this argument. Your assertions check the interaction, not the outcome.

The first verifies what the system did; the second verifies how it did it. Both are legitimate, but they fail differently — and the Hook is what happens when you use mocks for something a fake should have covered.

Classicist vs London, and why it matters

This is the classicist vs mockist (“London school”) split. Mockists mock every collaborator and assert interactions, so each unit is tested in total isolation. Classicists use real objects or fakes for collaborators they own, and reserve mocks for awkward boundaries. The practical consequence is coupling to structure: a fully-mocked test knows the exact call shape of its dependency, so any refactor that preserves behavior but changes call shape breaks the test. That is the forty-red-tests bug. Tests that assert through state survive refactors because they only care about the observable result.

Mock at the boundary, fake what you own

The discipline that avoids over-mocking: mock at the edges of your system, use real objects or fakes inside it. Code you own and control — domain services, your own repositories — can be wired together with real instances or in-memory fakes, so tests exercise actual collaboration. The things worth mocking are the boundaries you do not control or cannot afford in a test: the payment gateway, the email sender, the clock, the third-party HTTP call. These are exactly the dependencies where you want to assert “we called Stripe with this amount” because the call itself is the externally-visible effect. The seam is most valuable precisely at the system boundary — which is also where DI matters most.

Over-mocking is a design smell

When a unit test needs ten mocks to construct the subject, the test is not the problem — the design is. A class that requires ten collaborators is doing too much, and the painful test is the messenger. The reflex of a senior engineer is to read test pain as feedback about coupling, not as a reason to reach for more mocking machinery. Hard-to-test usually means hard-to-change.