alex88

alex88

I’m trying to mock ExTwitter during tests, I’m using GitHub - dashbitco/mox: Mocks and explicit contracts in Elixir · GitHub for that.

In my code I use a config variable to do the Dependency Injection, like this:

config :my_app,
  # DI
  twitter_client: MyApp.TwitterClient

I’ve defined my mock in test/support/mocks.ex as per Mox docs like this

Mox.defmock(MyApp.Mocks.TwitterClient, for: MyApp.TwitterClient)

and in my test.exs config I have

config :my_app,
  # DI
  twitter_client: MyApp.Mocks.TwitterClient

Everything worked while incrementally compiling during development, however on a fresh checkout without any _build folder i get this error:

== Compilation error in file test/support/mocks.ex ==
** (ArgumentError) module MyApp.TwitterClient is not available, please pass an existing module to :for
    lib/mox.ex:92: Mox.validate_behaviour!/1
    lib/mox.ex:84: Mox.defmock/2
    (elixir) lib/kernel/parallel_compiler.ex:121: anonymous fn/4 in Kernel.ParallelCompiler.spawn_compilers/1

if I remove that mock line, compile and add the line back everything works. It seems like it’s trying to compile the mock file first and then the lib folder.

My elixirc_paths is ["lib", "test/support", "test/factories"] so lib comes first, any idea?

I’ve pushed a sample app with the problem in https://github.com/alex88/myapp just run mix test

Showing Posts 1 to 10

ericmj

ericmj

Elixir Core Team

The Mox documentation suggests putting the Mox.defmock calls in test/test_helper.exs, that’s because the test helper is evaluated after all files are compiled. When you put the calls in the body of a compiled file it will try to check the mocked module is available at compile time which is a race condition.

hubertlepicki

hubertlepicki

This is actually incorrect, and also something you probably don’t want to do as you will lose compile-time compatability check of behaviors.

The problem is slightly different - i.e. the behavior is not properly specified here. I will publish a pull request for your repo @alex88 in a few mins to show you.

alex88

alex88 OP

That’s because there is no order in the compilation process?

Anyway, having the mocked module in the test config, when I move the mock into test_helper generates:

warning: function MyApp.Mocks.TwitterClient.configure/2 is undefined (module MyApp.Mocks.TwitterClient is not available)
  lib/my_app/stream/publisher.ex:9

warning: function MyApp.Mocks.TwitterClient.update_with_media/2 is undefined (module MyApp.Mocks.TwitterClient is not available)
  lib/my_app/stream/publisher.ex:22

warning: function MyApp.Mocks.TwitterClient.update/1 is undefined (module MyApp.Mocks.TwitterClient is not available)
  lib/my_app/stream/publisher.ex:25

so as per Mox — Mox v1.2.0 I moved the mock code into support/mocks.ex

to solve that I could this in my test helper:

Mox.defmock(MyApp.Mocks.TwitterClient, for: MyApp.TwitterClient)
Application.put_env(:my_app, :twitter_client, MyApp.Mocks.TwitterClient)

but is that the correct way?

hubertlepicki

hubertlepicki

hold on I’m investigating, some voodoo is going on here :smiley:

alex88

alex88 OP

Sure, just wanted to share all I tried at this point :slight_smile:

ericmj

ericmj

Elixir Core Team

Yes, modules will be compiled in the correct based on the calls or requires that is made in compile time. If you call a module at compile time the calling module will wait until the callee is compiled.

If it’s supposed to be supported to define behaviour implementations* at compile time then I think this line mox/lib/mox.ex at main · dashbitco/mox · GitHub should call Code.ensure_compiled? instead.

hubertlepicki

hubertlepicki

It’s not supposed to define new behaviours at compile time. Rather that it should create behaviour-compatible mocks based on already compiled modules, but you are right, it should be Code.ensure_compield?

ericmj

ericmj

Elixir Core Team

If you call Mox.defmock at compile time, which you do if you put it in the body of a file covered by elixirc_paths, then the function will call Code.ensure_loaded? at compile time. You will see that if you follow the stacktrace leading up to mox/lib/mox.ex at main · dashbitco/mox · GitHub. Calling Code.ensure_loaded? at compile is not safe because it’s a race to check if the module is loaded. If you instead call Code.ensure_compiled? then the compiler will wait until the given module is compiled, it works similar to require. You will notice that it works if you add a call to Code.ensure_compiled? before the call to Mox.defmock.

hubertlepicki

hubertlepicki

Yes, you are right ref the cause of the issue.

alex88

alex88 OP

I can confirm that changing from Code.ensure_loaded? to Code.ensure_compiled? fixes the issue while compiling and the app tests passes

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
RemyXRenard
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
asweet-confluent
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
samoloth
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

Latest on Elixir Forum

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews