3 ms·

If I’m reading it right, proposal is to hand-roll the mocks/test-doubles and store them in production code. (In addition to how to structure the app) While art

If I’m reading it right, proposal is to hand-roll the mocks/test-doubles and store them in production code. (In addition to how to structure the app) While article is interesting and idea workable, the title seems a bit misleading. (Including the “pattern language” part. I bet 90%of readers were expecting to see some kind of DSL)

loevborg 2y ago
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.
- knallfrosch 2y ago
  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.
  - earnestinger 2y ago
    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)
cluckindan 2y ago
> 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.
- jdlshore 2y ago
  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.
  - knallfrosch 2y ago
    > How are you imagining that variable gets flipped? Not by an external actor, but by an internal bug.

loevborg 2y ago

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.

knallfrosch 2y ago
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.
- earnestinger 2y ago
  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)

cluckindan 2y ago

> 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.

jdlshore 2y ago
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.
- knallfrosch 2y ago
  > How are you imagining that variable gets flipped? Not by an external actor, but by an internal bug.