I did watch the linked video and read through the Mox dox, so please know that I am taking all of your feedback seriously. Hopefully it becomes more clear once I have time to work on an example this weekend.
SeanShubin
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
100%, it is doing exactly this.
Right so the bit that I think is tripping you up is that that there are two distinct questions:
- What expectation functions should execute for the current caller pid.
- What should those functions return when they model something stateful.
Thing (1) there is where Mox’s pdict magic handles executing different functions for different caller pids. But the thing that makes all this work is that those functions have no intrinsic statefulness at all, which makes it trivial for you to add in whatever statefulness you want to adjust (2) in whatever way is best for your tests and the stateful system you want to manage. So you can do things like:
# In a test
{:ok, time_pid} = MyTestTime.start_link(initial_time)
Mox.expect(TimeMock, :monotonic_time, 2, fn ->
MyTestTime.get_current_time(time_pid)
end)
# run some that calls the MyApp.Time.get_current_time function, where MyApp.Time is a behavior.
assert blah
# Let's move time now!
MyTestTime.set_time(time_pid, my_new_time)
# run more code
I’ll try to get a more complete example for your code in a bit.
Fair enough! And I am sorry if I came on strong earlier. Your detailed replies are genuinely helpful, I feel like we are making progress here.
3
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
OK here we go!
https://github.com/benwilson512/mox_demo/blob/main/lib/mox_demo.ex
This has your main function. As you can see I have swapped out the System IO and File to the general IO behavior module I define here. mox_demo/lib/io.ex at main · benwilson512/mox_demo · GitHub
As I note in that module, it’s a bit simplistic to put all the IO functions in one module. In the real world you’d probably define multiple behaviors, but I wanted to keep this simple.
Then we have the test:
https://github.com/benwilson512/mox_demo/blob/main/test/mox_demo_test.exs
As you can see I can define test specific expectations. In the end I didn’t even really need to manage any state, since the ability to chain expectations meant that when you call eg monotonic_time twice I just define two expectations, one with the first value, and one with the second.
I don’t have additional tests in there right now but these expectations are 100% isolated from any other tests that would be happening.
One nice consequence of this approach is that backend being parameterized you still get strong compiler and language server support since it resolves to a compile time value.
This is barely scratching the surface of what’s possible though and ironically, a lot of what’s possible is made possible by how minimalist Mox is. Here is the same test set up a different way where it’s more interactive. Basically instead of setting up all the IO ahead of time and calling main(), we put main in a task and then have it basically “talk to” our test process as if it is the IO world:
https://github.com/benwilson512/mox_demo/blob/main/test/interactive_test.exs
All I’m doing here is combining core Elixir primitives like send and receive with Mox. Mox doesn’t really have any state to track here other than knowing which functions to call for this particular invocation of main. Then the “state” of the IO is in this case managed by my test process itself by sending messages to the mock at the appropriate times.
And of course you’ll note that you can just run mix test in the project root directory and these two test files will run at the same time and do not interfere. Both approaches are perfectly valid. I tend to favor the Mox.expect approach when I just have some outside system that I need a value or two from, or that I want to assert we pushed a value to. I tend to use the second approach if I’m writing more of a “simulator” test where there is some IO heavy piece of code and I want to step through it. This particular example makes that look sort of verbose but that setup block is generic. Once you write your little stub you’re done, and each test just gets to really focus on the interaction between the function under testing and the IO.
14
JohnnyCurran
The compile_env! tip is great –
Does this mean if you have:
@backend.i_dont_exist()
You’ll get a compiler error?
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
JohnnyCurran
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
ityonemo
If you don’t have sources of state as a behavior, it will not be testable with Mox
This is not entirely true. The mox documentation is confusing, it says “no ad-hoc mock without a behaviour”, which is true, but you can certainly create an ad-hoc behaviour and build your mock on top of that.
So even if your source of state doesn’t ship with a behaviour API no one will stop you from building you own that uh just so happens to look like the Module you’re building a mock for. Module calls are just apply/3 and they don’t enforce behaviour besides throwing if the function call doesn’t exist.
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I mean, that depends entirely on what you choose to implement with Mox. If you don’t have sources of state as a behavior, it will not be testable with Mox.
I do agree though that once you’ve got Mox in the mix there are many options available.
0
SeanShubin
Thanks so much for putting the work in, that was really helpful for my prototyping. You can see my various attempts here:
- GitHub - SeanShubin/testability_using_function_references · GitHub
- GitHub - SeanShubin/testability_using_fakes · GitHub
- GitHub - SeanShubin/testability_using_mocks · GitHub
- GitHub - SeanShubin/testability_using_mox · GitHub
Now that I got the mechanics down I can try to figure out which I like best and why, but I am too tired for analysis now. I wanted to post my results here in case anyone else is interested.
5