If a tree falls in the forest a process crashes during a spec run but nobody notices, did it really crash?

One way I’ve seen this manifest is code in a spec that GenServer.casts a message but doesn’t assert on any of the resulting side-effects. The fix could be to use :sys.get_state(target_pid) after the cast, which will do two things:

• wait for the cast to be handled and the target GenServer to check its mailbox
• ensure that target_pid is still running

Just getting the state is sufficient for that purpose, but you could also assert further that whatever the cast was supposed to do actually changed in the process’s state.

If the crash is logged to the stderr, I’d try using capture_log and seeing there were 0 error logs during the run of my tests… it wouldn’t catch the crashes that could happen in between the tests, but maybe it’s good enough?

LOL I’m a bot

I am not sure if this will work but I will just throw it.
I think during the setup of your tests, is to list the existing pids with Process.list/0, and on_exit run again Process.list/0 and compare the results and make sure the all pids in the first run are present in the run when exiting the test.

It may not work, depending on how your supervision tree and the process that dies.

That seems really fragile, there’s going to be background processes in other dependencies that may come or go and that isn’t really related to behavior under test at all.

Are you testing against your app’s supervision tree or are you spawning a copy of that tree for each test? I generally recommend the latter because it makes it far easier to test the processes, and you get to keep doing async: true.