Automating Tests in Elixir Projects

[D4no0]

@gaggle

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

If you plan on using separate modules, yeah, but generally you have a 2 module setup: the one that calls the external api and the one that does mocks.

@gaggle

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.

Give it a try for sure. This is no new concept and it’s much more easier to reason about compared to the complex setup that mocks require.

@gaggle

Ultimately I’m open to mocking 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.

Mocking internal logic for me is a hard no, this is one of the big reasons I try to avoid mocks whenever I can. The point of tests is to ensure correctness of your system at different levels. If you are mocking actual business logic, then you are introducing tests that can result in false positives which may cause more problems than they solve, as the code is a dynamic media that is always changing.