Resetting Mox mock after a single test

jrhite

I’m new to elixir and am seeing confusing/undesirable behavior when using Mox.

I just want to use a mock for a single test module. Let’s say I have 2 tests. Here is sample code:

defmodule MyTest do
  setup_all do
    defmock(DateTimeMock, for: DateTimeApi)

    :ok
  end

  test "test1" do
    {:ok, expected_datetime, _} = DateTime.from_iso8601("2019-09-08T00:00:00.000000Z")
    expect(DateTimeMock, :utc_now, fn _ -> expected_datetime end)
  end

  test "test2" do
    expect(something else)
  end
end 

defmodule MyTest2 do
  setup_all do
    defmock(DateTimeMock, for: DateTimeApi)

    :ok
  end

  test "test1" do
  end

  test "test2" do
  end
end

When MyTest2 runs I will see the error: (Mox.UnexpectedCallError) no expectation defined

Defining a mock for a single test ‘leaks’ out and affects all tests.

Does Mox have a way to revert the mocked module back to the original module after the test has finished?

9 comments

#mox

0 2891 9

2020-01-12 08:33:27 UTC

Showing Posts 1 to 9

Show Best Posts
Show All (oldest first)
Show All (newest first)

al2o3cr

Your example doesn’t show how DateTimeMock is used - how is code in MyTest2 interacting with it?

For instance, do you have the mock set in application config? In that case EVERY test will hit it. stub might be the way out.

Post #1

jrhite

In my case I’m assuming I’m working with a legacy code introducing Mox. So MyTest2 doesn’t have any expects. Thus it fails. Yeah I’ve been able to use stub_with to get around that issue, but it feels very hacky.

Post #2

LostKobrakai

There are a few things. Mock modules of Mox are empty shells. Without expectations/stubs they don’t know what to do/return when being called. Therefore there’s a technical requirement to setting up expectations/stubs.

The other part is that you don’t want to have tests, which do not tell you about the usage of a mock. Without expectations/stubs being setup in a testcase any other developer might think the same code is run as is in production, which is not true.

If you don’t want to have to setup stubs/expectations for your mock “everywhere” the best solution is to not use the mock for those testcases, but e.g. a module with a dummy implementation or even the prod implementation.

Aside:
You should put your defmock calls in test_helpers.exs and not in your setup functions. defmock creates a module and modules are always global to the beam instance. You cannot scope those to a single test unless you use different names.

Post #3

jrhite

That’s just the info I was looking for. Thank you.

I put the defmock in the test module itself instead of test_helpers.exs as an attempt to scope the mock to this test only.

I was was hoping there might be a function like JS Jest’s mockRestore. After a test it restores the mocked module back to the original module implementation. This allows for easy mock integration into a legacy system where it’s not feasible to update all tests at once. It seems like, in theory, Mox should be able to store the original module away in the Mox Genserver and restore it after the test exits.

Possible good feature request?

Post #4

jrhite

And yeah, I was thinking about just using stub_with() with the prod implementation for the other tests that have not yet been upgraded to use, but restoring the mock to its original implementation after a test seems like better test to test isolation.

Post #5

al2o3cr

Mox doesn’t have this feature because that’s not how it works - somewhere in your test setup / config, code is storing DateTimeMock in a spot where production stores DateTimeApi. The docs show two possible forms, but your code may do something different:

config :my_app, :calculator, MyApp.CalcMock
# or
Application.put_env(:my_app, :calculator, MyApp.CalcMock)

What you’re describing is closer to the behavior of tools like :meck which manipulate module resolution at runtime. That comes with a whole new set of weird behaviors (for instance, code coverage can fail unexpectedly).

Post #6

ityonemo

You don’t need to do that. The tests can run concurrently and you never know what order they will run in because order is randomized. Every test lives in its own beam process. Mock often can see what process was responsible for what chain of events and so if you do it right, changes you make to the mocks are contained to your test process and its friends (for some value of “friends”) and the whole universe of that testing setup is thrown away at the end of the test.

This is what makes elixir testing awesome, btw, When you get really good you can run all of your tests (even integration tests that escape the BEAM) concurrently without stomping on each other’s view of what the VM should look like.

Post #7

jrhite

I see, thanks for the explanation.

I think the best solution in my case would be to create the Mox mock in test_helper and then also use stub_with using the real implementation for tests that haven’t set expectations yet. Then the team can change the tests over on a test-by-test basis.

Post #8