Can't figure out how to assert error in linked process with ExUnit

Questions / Help
, , ,
1

I am using an Agent for state. Nothing I have tried for asserting an ArgumentError raised in the Agent has worked! The test fails and the process dies without the assertion working.

Here’s some code that demonstrates. In this function add_action, I want to verify that the value of the map key :actions is a list, and hasn’t been changed to something else.

def start_link do
  Agent.start_link(@name, :init, [], name: @name)
end

def init do 
  %{actions: []}
end

def add_action(action) when is_atom(action) do
  Agent.get_and_update(@name, fn(map) ->
    result = Map.update!(map, :actions, fn
      list when is_list(list) -> [action | list]
      _ -> raise ArgumentError, message: "key :actions is not a list!"
    end)

    {result, result}
  end)
end

Here is the test:

setup do
  {:ok, pid} = State.start_link
  [pid: pid]
end

test "action example", context do 
  # assume State.actions is `42` here instead of `[]`
  assert_raise ArgumentError, fn ->
    # the process dies here, so `assert_raise` is never called
    State.add_action :failure 
  end
end

I have tried catch_exit, catch_error, catch_throw, catch_pokemon, Process.monitor, receive, etc. No matter what, I still get this error message

=ERROR REPORT==== 1-Oct-2016::19:39:16 ===
** Generic server 'Elixir.ManOrActionMan.State' terminating 
** Last message in was {get_and_update,
                           #Fun<Elixir.DepsInstall.State.0.35286781>}
*snip*

I can’t seem to figure out how to catch that ArgumentError, or if that’s even the right approach to raising errors in a process.

Any help is much appreciated!

2

I cracked up at catch_pokemon. :laughing:

You can’t catch the error because it doesn’t happen in the test process. Test it as follows:

  1. Have the test process trap exits
  2. assert_received on the {:EXIT, …} message

Hope that helps.

2 Likes
3

Thanks! I tried that, but I can’t seem to make it work, the process still fails before it gets to the receive. Does this look right?

test "action example", context do
  # assume State.actions is `42` here instead of `[]`
  Process.flag :trap_exit, true
  # process still dies here with same error :(
  State.add_action :failure
  raise "You've got fail!" # never gets here
  receive do
    anything -> IO.inspect anything
  end
end
4

Trapping exits means that the test process won’t be terminated when the linked process terminates. The call to State.add_action :failure will still fail though so you’ll need to catch_exit it.

Btw, I am also wondering why are you getting exits formatted using the Erlang logger instead of the Elixir one in your initial report. :slight_smile:

1 Like
5

Thanks @JEG2 and @josevalim by your powers combined I am Captain Solution! The tests are passing now. :heart:

In case anyone else ever stumbles through this, here’s my final(?) working test:

test "fails if actions is not a list", context do
  State.set_actions 
  Process.flag :trap_exit, true
  catch_exit do
    State.add_action(:secret)
  end

  pid = context[:pid]
  assert_received({:EXIT, ^pid, {%ArgumentError{message: "actions is not a list"}, _}})
end

@josevalim Your message prompted me to remember that I removed :logger from mix.exs a while ago as a newbie mistake; putting it back changed the Erlang error to an Elixir one. I still see an error print out during the test run, but it passes. I’m sure it’s my fault somehow. :smiley:

5 Likes
6

Great! Btw, adding “@tag :capture_log” before the test should silence the
log reports.

4 Likes
7

Yeah, sorry about this. As @josevalim pointed out, I led you astray. To try and make up for it, I’ll try to explain why this happens.

The other process dies during a GenServer.call() (Agent is just a wrapper over the GenServer layer.) If the called process dies mid-call, GenServer (or really the lower layer gen_server) will try to exit the current process.

That sounded radical to me when I first learned of it, but it makes sense, if you think about it. GenServer.call() is expected to return a value and there’s no return value that makes sense. The expected flow of operations cannot continue.

Anyway, I hope that helps. Sorry I didn’t take the time to actually understand your problem to begin with.

2 Likes
8

To be honest, it also took me a while to figure out why trapping exits was not enough. :slight_smile:

9

Any way to test similar things for non-linked processes? Like tasks under a different supervisor, so no way to trap exits. How can we ensure tests in those scenerios?