Yes, I think it's fair to say that nullables are a form of test doubles. But the approach is meaningfully different from other approaches as it avoids the problems that you get from using mocks in the narrow sense of the word: you're only testing against the behavior of the mocks (not the real code) and you need to keep updating the mocks as the system changes, which adds maintenance cost.

I don't really see how production-code mocks differ from library-based mocks. If you add but a single constructor parameter to your class, you already need to change your production-mock/stub too.

the benefits I see:

- nullable (test double/mock) updates would be more natural, easier, since it is located right there in prod code. (One level of indirection removed)

- with authoritative location of test double, it reduces the risk of test double proliferation/duplication

(I doubt I will use it in the proposed form though, saving test double code in prod is not for me probably)

> LoginClient.createNull().getUserInfo(...) should return a default response without actually talking to the third-party login service.

This seems like a security nightmare. In defense terms: here’s the side road to the castle with gates open, guarded by a single variable.

How are you imagining that variable gets flipped? If an attacker has the ability to run arbitrary code, you’re already screwed.

To put it another way, somewhere in your code you do authorization: `if (isAuthorized) enterTheCastle()`. The gate to the castle, guarded by a single variable. In both cases, you have to be careful to program it correctly.

In the case of Nullables, it’s easy to program it correctly. Multiple things would have to go wrong for the nulled version to be accidentally used in production. Also, unless you go out of your way to make a security vulnerability, Nullables’ default behavior is to do nothing. They default closed rather than open.

> How are you imagining that variable gets flipped?

Not by an external actor, but by an internal bug.