The biggest problem I feel people have with testing “global” processes, is that the fact that they’re hard coded to be global. Things get quite a bit simpler if naming a process (or registering elsewhere) becomes something controlled by start parameters, where an application started instance can still make sure its registered, but e.g. tests can easily start their own instances unnamed and therefore be more flexible in how to test the complete livecycle of the process.

Instead of testing the processes started by your application start another set of those processes for testing the interactions. Basically splitting up the parts of “the processes are started as part of the application” from the tests about “assert that the processes correctly interact with each other”.

Okay, well, this post seems to imply that long-running Tasks are almost an anti-pattern, and you should instead use a genserver: Best way to name permanent tasks? - #8 by ityonemo

The TL;DR as it applies to my issue involves using Process.register inside the Task module, so it’s named. And, also, to probably not use a Task, and instead use a GenServer.

I will attempt to rewrite my Task as a GenServer. It seems a bit like overkill, but maybe the added functionality potential will serve me well in the long run. What do you think @LostKobrakai ?

So, it seems like you are building some sort of “random number service” as the Agent. I guess, my question to you would be then why not just use a single GenServer and instead of using a task to generate your numbers, generate numbers in your GenServer between requests (you could probably also do this with Agent, but i kind of have a bias against Agent, in almost all cases you should not be using Agent). Do you really need the number generation to be asynchronous? Because once it becomes asynchronous, your complexity increases, you need to think about strange failure modes (what happens when the Task disappears but not the Agent? what about vice versa?), and if you have a “synchronous” genserver service doing the generation, then you only have to think about one line of execution and stuff stays (relatively) sane.

You could also build out a single instance of the server and test it in isolation.

Finally, if you are really adamant about having this Agent/Task architecture, I would put the Agent and the Task under a common supervisor, and start a “fresh supervisor” in every test you run. Don’t forget to hoist the “naming” option to an option in the supervisor setup, so that in your Application.start call it gets properly named, but when you spawn off new ones for testing, they’re not bound to a locally unique name

you might want to do something like :timer.send_interval(interval, self(), :tick) on init, Erlang -- timer if you need the generation to be triggered indepedently of other events happening to your GenServer and even if no other events happen.

My personal preference is that I don’t like Process.send_after(self(), :tick, interval), because it feels like you if you are not careful coding, you could accidentally retrigger it n times and wind up with n times more events than you wanted.

If you only need it in a responsive sense (only need to update the list after some event has happened), I recommend using the handle_continue, I think if you can get away with doing that that is the best way, because your event schedule is more “deterministic” for testing purposes, and probably it’s easier to reason about.