I cracked up at catch_pokemon.

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.

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

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.

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

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.

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

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.

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

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?