How to mock unit tests but not integration tests? (Using Mox ideally)

woohaaha

I’m trying to wrap my head around using mocks in Elixir. There are a lot of blog posts on the subject but I’m not seeing any that address my use cases.

(no need to recommend Mocks and explicit contracts « Plataformatec Blog, read it a few times )

To be a bit more specific, here are my scenarios/questions:

I would like my integration tests to write-to/read-from the database. I don’t want my unit tests to touch the database. I’d like to use a mock for the persistence layer. How can I do this with Mox? It seems all the examples require one into an all-or-nothing commitment. You’re either using the DB or not.

On dependency injection… I don’t mind injecting a mock Repo in my unit tests but I don’t understand how that scales into intermediary modules when I have to test those. For example:

defmodule MyApp.Accounts do
  def list_users(repo \\ MyApp.Repo) do
    repo.all(User)
  end
end

defmodule MyApp.Dashboard do
  # do i inject MyApp.RepoMock here? i'd need to DI all these functions. how do i test with mocks in this context?
  # def get_the_world(repo \\ MyApp.Repo) <---- ???
  def get_the_world() do
    so_many_users = MyApp.Accounts.list_users(repo)
    MyApp.AnotherContext.more_stuff_to_mock_stub(MyApp.DI1)
    MyApp.Context3.yup_more_goes_here(MyApp.DI2)
     ...
  end
end

Would appreciate it if someone can explain how I can use Mox in unit tests and not in integration tests. Would also like to know how DI works without having to pass modules through multiple layers just to have precise control in my unit tests.

Thank you

13 comments

#ecto #repo #http-requests

3 2610 13

2019-11-23 02:39:56 UTC

Showing Posts 1 to 10

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

rodrigues

Hi @woohaaha, in Mox v1.2.0 — Documentation you can see how to set a mock using application env as dependency injection:

Application.put_env(:my_app, :calculator, MyApp.CalcMock)

You can have some tests doing that, while other tests use the non-mocked implementation:

Application.put_env(:my_app, :calculator, MyApp.RealCalculator)

To see how to do this in ex_unit, you can take a look at setup and ExUnit.CaseTemplate.

Post #1

axelson

Scenic Core Team

Note: if you use that approach during a test then you need to ensure that test is marked as async: false since the application env is global. But if you only called put_env in your integration tests and marked them as global that could work well.

Post #2

woohaaha

@axelson, indeed i want async: true so I’m not sure Application.put_env(:my_app, :calculator, MyApp.CalcMock) in some tests and not in others will be reliable.

I’m not sure what you mean here. Running the tests as a suite means that setting the environment during integration tests will leave it set for any follow on unit tests, no? Are you suggesting I run integration and unit tests separately? I’m not sure how marking them as global (set_mox_global?) changes those concerns.

Post #3

woohaaha

Thank you @rodrigues for the reply. @axelson had some points related to your answer which mean the tests could be flaky, no?

Post #4

woohaaha

Not sure how to update the original question as the Edit button is missing… but here’s an update.

I would prefer to run the tests concurrently.

I do not need Mox (just thought that was the right tool for the job… but what do i know?).

(I am willing to split my test suite to only running integration tests, and then the unit tests separately… but that would make me sad )

I have done a lot of reading at this point as there’s plenty of articles out there, but nothing to address my requirements (which I think are realistic). It could also be that maybe I just don’t get it so… can anyone explain it to me like I’m 5? Or, better yet, since this is a topic I’ve noticed some people get heated on, maybe someone could write a blog post or create a youtube video showing exactly how it should be done? (In a real world-ish example, like a Phoenix app with integration tests and unit tests and it all being concurrent)

Post #5

ityonemo

Use Mox.
For your unit tests, do the normal Mox thing.
For your integration tests, use stub_with and stub out to the unmocked module, this will make a database call.
read up on how to make Ecto tests async.

Post #6

axelson

Scenic Core Team

I was suggesting that you could use the Application.put_env approach for all your integration tests and mark them as async: false. But I’d second @ityonemo’s approach of using Mox.stub_with in your integration tests. That will work for most cases as long as you aren’t spawning additional processes.

Post #7

ityonemo

It also work with all spawned processes linked with the Task module (which is one reason why you should always always always use Task in your code)

Post #8

woohaaha

Thank you for that. I read up about Task (Task — Elixir v1.20.2). I’ll need to find the common use cases for Task so will search for that.

Post #9

ityonemo

I should be careful. What I mean is “always always use Task instead of a naked spawn or spawn_link”. If you don’t need async (most of the time you don’t), don’t use a Task.

Post #10

Load more posts (3 remaining)