Hey all,
we’re lately running into problems, dispatching events in a (phoenix) context to trigger some other work. It can either be starting some additional processes in the supervision tree or notifying a different process which will then query some other data.
The first case sometimes throws us up in testing, because it will spawn some processes which we didn’t want to in the specific test, just because we created a new entry for the database.
The later case has some issues for us in testing with Ecto.Adapters.SQL.Sandbox because the process which we triggered is not in the allowed process list. And it’s not registered under a global name, so it would take some effort to put the process in a registry, just to find it in testing.
It feels like we didn’t architect this correctly.
- Is there a pattern to solve this architecture problem?
- How do you write or set up the tests to work around this problem?
- Is it common to not start the supervision tree in tests? That would at least prevent the other notified processes to execute.
- Is it legit to write logic which prevents the side effects in testing? Because, it seems to me, that we are just working around the problem in not testing that part of the code/behaviour.
I hope to get some input and ideas for this problem. Feel free to start a discussion or send me am PM.
