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.
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.
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.
@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.
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)
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.
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.
…and now since I’m being pedantic, there are times when you want to use spawn(), for example, if you’re doing a test and you really want the parallel process to explicitly not be associated with existing test process (I have done this)
)
)
