unti test shouldn’t call db at all - it should be small, super fast, async, and isolated.
anyway calling db was one of 3 examples - why did u ignore the rest two?
dependencies on other processes, more complex test setup - which often leads to NON async tests
and these were just examples - there might be more problems like name: MODULE (u cannot spawn more processes with the same name, so u can’t run tests in async way) - the list goes on
I ignore them because they’re meaningless. You should not pass env to a protocol implementation but define implementations based on the environment. Then your code uses the protocol itself and doesn’t care about the implementation or the environment.
Hardcoding names to processes is another code smell you apparently use. Always keep the option to start a non-named process.
If we’re talking about unit tests, why are you not keeping your functions pure? Why they start processes which involve database calls?
P.S. me and @mudasobwa talk about the same thing. Just two different ways to achieve it.
how problems such as more complex test setup, dependencies on other processes - which often leads to NON async tests, and db calls that shoudn’t happen in unit tests are meaningless?
I never did - I just asked if I correctly understood u but I didn’t get response for it
Always keep the option to start a non-named process.
that’s not a solution for where u calling genserver very deep down in a code - unless u pass process name through dozen function which is smell too
why are you not keeping your functions pure?
because we write systems that have to do sth - we cannot have all functions in entire system pure
I didn’t
you wrote HTTP call or spawning a process is already a dependency.
so I asked if I should abstract away GenServer call like we did with HTTP calls - that was just a question
The proper design is the GenServer is not tied to
That’s the ideal design, and I completely agree. Thanks!
But I live in the real world, where not every project is designed that way. I have to work with the codebase as it is, because I can’t realistically refactor a 500k-line project while also delivering my day-to-day work, sorry
Then ask that and I’ll respond. The example you supplied has nothing to do with that particular question. Answering this, yes, you should make the GenServer implementation a dependency, and use mocking library to validate it has been properly called (besides returning whatever is needed for tests all the turtles down.)
Then please stop arguing that mocking whatever is good. I accept the argument “it’s lame, but I have neither courage nor ability to do it right.”
so strong. I think in the busy of work I forgot to check-in, but this does seem a bit off the rails of the original conversation. Thank you all I’ve found uses of both where I work. I am indifferent to injection vs patching arguments; both seem valid to me. I was really hoping there might be something that can be injected or patched like VCR in the python world; where it records a http, and then checks the code still conforms to that. I like it’s golden master style and also that updating is considered in the framework, as well as network isolation and provision for erroring if network access is attempted on some non-mocked / unexpected endpoint is reached. I think in this AI world, having knowledge of access to unexpected / new networks brings good habits; but again, strong opinion, weakly held
This is a very specific assertion which vcr absolutely deals with. Error codes, dns lookups. There is nothing in code which cannot be used to simulate error cases
I might not have fully grasped the exact request in the post, but for interactive testing and exploring—or even replacing—external tools like Postman or WireMock, the combination of Livebook, Req, and Kino seems brilliant to me. To be honest, I haven’t tested it yet, but if I were to do so, I think that’s where I’d start—wouldn’t you?