One problem with using the application environment for injection is that tests don’t run concurrently, right? I shouldn’t argue it’s not simple though - you’re right, it’s a global key-value store. But I find it surprising when runtime code reads from it not for user-configurable settings, but purely as a mechanism for injection. It feels like an awkward fit to me (as elucidated in the blog).
Personally, I find it easier to reason about when a process gets its dependencies from its own process hierarchy — and as a bonus, it enables async tests. But: Just opinions. It’s a wide tent, and many ways to success. What matters most must be that the team is effective and having fun within whatever is the chosen setup.
I’m smiling at the HTTP discussion - it’s revealing more nuance than I’d considered: I also don’t want to mock HTTP, but I’ve typically placed those kinds of tests higher up, e.g. E2E. But Bypass sounds great - I’ve added it to my to-investigate list so I can make sure I understand it properly.
Ultimately I’m open to test doubling internal modules when they grow too large or too entangled to fit in our heads, because I’ve seen devs really appreciate the clarity that comes from such decoupling. So I’ve got a net-positive view on this kind of approach - as long as we use the simplest (not always easiest) ways to do it. And I appreciate the engagement here, it’s a nuanced topic.
