woohaaha
How to use Mox for a module you own?
I cannot seem to get Mox to work for my Accounts module. Here is sort of the code.
# test_helper.exs
ExUnit.start(exclude: [:skip])
Mox.defmock(MyApp.MockAccounts, for: MyApp.Accounts)
# my_app/accounts.exs
defmodule MyApp.Accounts do
@callback get_role(map()) :: :admin | :user
def get_role(current_user) do
# temporary authorization hack
# yes, i am using my real email (note, real email is not being used here)
case current_user.email do
"myrealemail@gmail.com" -> :admin
_ -> :user
end
end
# test/integration/admin_area_only_test.exs
defmodule MyApp.Integration.AdminAreaOnlyTest do
use MyApp.ConnCase, async: true
import Mox
setup :verify_on_exit!
test "admin area only" do
MyApp.MockAccounts
|> expect(:get_role, fn(_user) -> :admin end)
# email used here is different because I don't want personal email in tests (yes, a bit ironic, but here we are)
{:ok, user} = MyApp.Accounts.create_user(%{email: "hi@example.com", password: "123"})
conn =
session_conn()
|> put_session(:user_id, user.id)
|> put_session(:current_user, user)
etc...
# assertions
# it fails because user doesn't have permission
I would rather not have to modify prod.exs, test.exs, and dev.exs because that means I’ll have to use Application.get_env for my Accounts module which is used everywhere. All the Mox examples are used for small libs and external requests like Httpoison but what about an internal module?
Any direction would be greatly appreciated.
Thank you
Most Liked
LostKobrakai
It’s not really an issue of external vs. internal modules.
You seem to be expecting mox to be able to intercept function calls, which is not possible on the beam. If you call MyApp.Accounts.create_user it’ll call the given module and not MyApp.MockAccounts. There’s no way to intercept calls to MyApp.Accounts and make them be magically resolved by the function on the mock module.
If you want to use mox you need to have means to switch out the real implementation with the mock implemenation in your codebase, so the functions are actually called on the mock module of mox. This can be done using the app env, but there are also other ways to inject the mock module.
Often those means are created automatically for things you expect to switch out anyways like http clients. That might make you feel like Mox is catered specifically for those elements. But the same mechanisms do work for switching out any real implementation with an mocked one. No matter what the code is about.
No matter how you’re going to deal with dependency injection (app env or not) you’re correct in that you don’t want to concern the callers of functions on MyApp.Accounts with the decision which implementation to call. But you can move the code you currently have in MyApp.Accounts to e.g. MyApp.Accounts.Impl and do the decision making within MyApp.Accounts. For every function either forward to MyApp.Accounts.Impl or use a different module, which was somehow injected to be used.
egze
To add to this:
- Have a look at https://github.com/sascha-wolf/knigge It can simplify the boilerplate.
- Maybe it’s just my preference, but for behaviour
MyApp.Accountsname the implementation -MyApp.AccountsImpl. Then if you use the quick find function in editors, if you typeAccounts, you will see both. (some editors like VSCode will find both even in your case, but not all editors). Also I name my mock -MyApp.AccountsMock
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Develop your skills with books, videos, and courses.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"