I'm pretty fond of this article. I think it's an interesting approach, and I think you can generalize it out into some very useful principles.

The big takeaway, I think, is that a particular module of code should encapsulate its own test double configuration & injection behind a set of testing factories. So rather than this:

    m = new FooMock()
    m.call("Bar", 1, 2)
    m.call("Baz", 3)
    p = new thing.ThingDoer(m)
    actual = p.doThing()
    assert(expected == actual)

Do something like this:

    p = thing.makeThingDoerForTest(1, 2, 3)
    actual = p.doThing()
    assert(expected == actual)

Shore's "nullables" are a version of this, but to me it doesn't really matter what makeThingDoerForTest is doing internally to build the mocked-up test version of a ThingDoer. What matters is that the test doesn't have to worry about it: It's the Thing module's responsibility to correctly set up the test doubles involved. The unit test can use a special constructor that exposes only the minimum necessary configuration, and then implementation details about how ThingDoer interacts with Foo can be hidden inside the Thing module, as they should be.