I think the big benefit comes from hiding implementation details away from tests. Here—let me copy-paste an example I used elsewhere in this thread: --- With

I think the big benefit comes from hiding implementation details away from tests. Here—let me copy-paste an example I used elsewhere in this thread: --- With mock injection: m = new FooMock() m.call("Bar", 1, 2) m.call("Baz", 3) p = new Thing(m) actual = p.doSomething() assert(expected == actual) With a test-specific factory method: p = Thing::makeTestThing(1, 2, 3) // static method actual = p.doSomething() assert(expected == actual) With the test-specific factory, mocked dependencies are encapsulated by Thing. You can configure the their behaviour by passing different parameters to the factory method, but implementation details like `m.call("Bar", 1, 2)` are hidden. The test doesn't need to know that `doSomething` calls `Foo.Bar`. I'm not sure whether the author of the article would consider `Thing` to be a nullable if `makeTestThing` uses a conventional, automatically-generated `FooMock` under the hood, but I don't think it really matters. To me, the big benefit comes from `Thing` assuming the responsibility to configure and inject its own mocks.