You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No ad-hoc mocks. You can only create mocks based on behaviours
No dynamic generation of modules during tests. Mocks are preferably defined in your test_helper.exs or in a setup_all block and not per test
Concurrency support. Tests using the same mock can still use async: true
Rely on pattern matching and function clauses for asserting on the
input instead of complex expectation rules
The goal behind Mox is to help you think and define the contract between the different parts of your application. In the opinion of Mox maintainers, as long as you follow those guidelines and keep your tests concurrent, any library for mocks may be used (or, in certain cases, you may not even need one).
Just add mox to your list of dependencies in mix.exs:
defdepsdo[{:mox,"~> 1.0",only: :test}]end
Mox should be automatically started unless the :applications key is set inside def application in your mix.exs. In such cases, you need to remove the :applications key in favor of :extra_applications or call Application.ensure_all_started(:mox) in your test/test_helper.exs.
# lib/weather_impl.exdefmoduleWeatherImpldo@moduledoc""" An implementation of a WeatherBehaviour """@behaviourWeatherBehaviour@implWeatherBehaviourdefget_weather(city)whenis_binary(city)do# Here you could call an external api directly with an HTTP client or use a third# party library that does that work for you. In this example we send a# request using a `httpc` to get back some html, which we can process later.:inets.start():ssl.start()case:httpc.request(:get,{"https://www.google.com/search?q=weather+#{city}",[]},[],[])do{:ok,{_,_,html_content}}->{:ok,%{body: html_content}}error->{:error,"Error getting weather: #{inspect(error)}"}endendend
3) Add a switch
This can pull from your config/config.exs, config/test.exs, or, you can have no config as shown below and rely on a default. We also add a function to a higher level abstraction that will call the correct implementation:
# bound.ex, the main context we chose to call this function fromdefmoduleBounddodefget_weather(city)doweather_impl().get_weather(city)enddefpweather_impl()doApplication.get_env(:bound,:weather,WeatherImpl)endend
4) Define the mock so it is used during tests
# In your test/test_helper.exsMox.defmock(WeatherBehaviourMock,for: WeatherBehaviour)# <- Add thisApplication.put_env(:bound,:weather,WeatherBehaviourMock)# <- Add thisExUnit.start()
5) Create a test and use expect to assert on the mock arguments
# test/bound_test.exsdefmoduleBoundTestdouseExUnit.CaseimportMoxsetup:verify_on_exit!describe"get_weather/1"dotest"fetches weather based on a location"doexpect(WeatherBehaviourMock,:get_weather,fnargs-># here we can assert on the arguments that get passed to the functionassertargs=="Chicago"# here we decide what the mock returns{:ok,%{body: "Some html with weather data"}}end)assert{:ok,_}=Bound.get_weather("Chicago")endendend
Enforcing consistency with behaviour typespecs
Hammox is an enhanced version of Mox which automatically makes sure that calls to mocks match the typespecs defined in the behaviour. If you find this useful, see the project homepage.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
https://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.