That is why I use a factory function, I expect I will be able to create other factory functions or parameterize existing factory functions to consolidate that kind of complexity as necessary.
That certainly is a tradeoff to balance against. Thanks for pointing it out.
No they aren’t. You keep saying this, and we keep trying to tell you that this isn’t how Mox works. Please watch the linked video, or read through the Mox docs. It’s literally bullet point 3 of Mox — Mox v1.2.0
The state I am worried about is things like recording side effects in IO.puts, or specifying external behavior in things like System.monotonic_time. So far this is the simplest solution I have been able to come up with to test these kinds of interactions. If I have one nondeterministic module that two other modules depend on, I don’t know how to get that nondeterminism under test coverage except by creating state to keep track of what is going on, and I don’t know how keep that state from getting clobbered during an async test without dynamically generating a namespace within which to store that state. Using dynamically named modules solved the issue of state collision, while at the same time minimizing my need to change the production code because the fake module appears to be no different from the real one from the perspective of the code that depends on it.
I think you’re missing some fundamentals of how the BEAM works:
State is not stored in namespaces either, it is stored in processes. Though it’s also not clear what you mean by namespace.
Perhaps I’m not the best person to give an eloquent answer here, but if you’re talking about the pattern of naming a GenServer after a module, it is merely a convention and is simply just a name that happens to match the module’s name—it has nothing to do with the module itself. You can call a GenServer whatever you like. If you really want to track state during tests runs then you should could could start an Agent or something for each suite. But again, state is stored in processes, not modules. Each test file runs in its own processes. They can’t touch each others’ state.
I did not know there were process dictionaries that were isolated from each other, I thought my only choice was to use a dynamically generated global name. However, even with a process dictionary, as far as I can tell, I still need state to test nondeterminism, which means I need a process to manage that state, which means I still need a dynamically generated name. Mox appears to help me create a production and test version of a module, but what I think I need is a production version and multiple test versions with their own state.
The video was interesting, as are process dictionaries, thanks for drawing my attention to it.
That is a good argument to specify the production implementations as defaults, that way there is no intrusion into calling modules. I had taken them out of the example for simplicity’s sake, but your observation certainly justifies putting the defaults back in. As for the intrusion into functions within the module itself, yes it is more verbose, but it also makes it more obvious where nondeterminism is going on, so I suspect this will actually make it easier to reason about where to place abstraction boundaries.
Using defaults also makes the callers not affected for in the tests, and the tests are necessarily affected as they have to manage the state to keep track of the nondeterminism. It is not the modules or functions that make this troublesome, it is the need to maintain state to keep track of the nondeterminism.
You are conflating functions and state. When you set up Mox |> expect in a test you are attaching functions that will be called for the test in question, as distinct from any other tests. There is no state at all in that. If you want to add state you can choose to do so by say, spawning a genserver for each test, and then calling out to that genserver within the |> expected functions for each test. This would be 100% deterministic and isolated for every test.
I may have time later and I’ll sketch up an example of what this looks like for IO and time. You’re still approaching this from an OO world where the functions and state are bound.
Pile on all you like, the feedback is really helping me understand and articulate the problem I am trying to solve better.
I share your passion, with the caveat that this does not apply to tests that are helping you detect that you have drawn an abstraction boundary incorrectly.
I suspect we agree, but I want to be more precise by saying I think the crux of the issue is making sure the tests are empowering us to identify and isolate sensible abstraction boundaries, and that deterministic vs nondeterministic code is the most important of all such boundaries.
Not each implementation, but certainly each implementation containing nondeterminism. I am not so sure it is a step backwards to be more explicit about where the nondeterminism lies, especially if you value “functional” programming.
That would be true if I didn’t have to contend with different tests needing different state, and if I had one implementation for prod and a separate implementation for test, but it is my impression that because of state I actually need multiple test implementations.
You would never have to pass in a reference to something that only contained pure functions.
Not every dependency, just every dependency that contains nondeterminism. I am not so sure it is bad practice to be explicit about where the nondeterminism lies, especially if you want to encourage “functional” style for most of the code. Being more explicit about nondeterminism can actually make it easier to reason about where to draw abstraction boundaries. I would hope to isolate the nondeterminism and modules that depend on it as much as possible, leaving the vast majority of the code base pure functional.
Hmm, so perhaps Mox is somehow using the process dictionary to keep expectations isolated? I am not trying to be dense, perhaps I am just getting tripped up on the wording. I keep hearing how Mox allows for separate implementations when I am worried about separate state. Over the weekend I should have time to create a prototype using Mox, so hopefully I will either address my own concerns or be able to articulate them more precisely.
I intend to get this example under 100% test coverage
defmodule Hello do
def main(args) do
time_unit = :microsecond
microseconds_before = System.monotonic_time time_unit
target = args |> List.first |> File.read!
IO.puts "Hello, #{target}!"
microseconds_after = System.monotonic_time time_unit
microseconds_duration = microseconds_after - microseconds_before
IO.puts "Took #{microseconds_duration} microseconds"
end
end
Also, I don’t mean to be repetitive, I was addressing each reply in order. I do appreciate you all taking the time to help me understand.