Why avoid mocks



Ok, cool. I’m very happy to know what you think about MecksUnit. And btw, I just pushed a new version in which defining mock modules are done far more elegantly :slight_smile: :muscle:

defmodule Foo do
  def trim(string) do

defmodule MecksUnitTest do
  use ExUnit.Case, async: true
  use MecksUnit.Case

  defmock String do
    def trim("  Paul  "), do: "Engel"
    def trim("  Foo  ", "!"), do: "Bar"
    def trim(_, "!"), do: {:passthrough, ["  Surprise!  !!!!", "!"]}
    def trim(_, _), do: :passthrough

  defmock List do
    def wrap(:foo), do: [1, 2, 3, 4]

  mocked_test "using mocked module functions" do
    task =
      Task.async(fn ->
        assert "Engel" == String.trim("  Paul  ")
        assert "Engel" == Foo.trim("  Paul  ")
        assert "Bar" == String.trim("  Foo  ", "!")
        assert "  Surprise!  " == String.trim("  Paul  ", "!")
        assert "MecksUnit" == String.trim("  MecksUnit  ")
        assert "Paul Engel" == String.trim("  Paul Engel  ", " ")
        assert [1, 2, 3, 4] == List.wrap(:foo)
        assert [] == List.wrap(nil)
        assert [:bar] == List.wrap(:bar)
        assert [:foo, :bar] == List.wrap([:foo, :bar])


Please note that you have to use defmock and mocked_test. Nice, huh?


Does it work if String.trim is called outside that block?


You mean indirectly? Then the answer is yes. I have added the module Foo within the example which invokes String.trim() and the tests succeed


@archan937 does this also work with multiple processes?


It works when running tests asynchronously (which produces child processes) if that’s what you mean. Could otherwise give an example of a different setup with multiple processes?


Released MecksUnit v0.1.2 in which you can assert function calls with either called (returns a boolean) or assert_called (raises an error when not having found a match):

assert called List.wrap(:foo)
assert_called String.trim(_)