Designing an Agent with side-effects on start_link

I would do this with a GenServer (I do not use Agent). Not in start_link, but in the init function…

There is even a handle_continue to avoid blocking when initialization is long.

How would you test that? When I run mix test the Supervisor spins up all its children, including that one and all modules mocked with Mox are loaded.

That means that @my_service.get_api_response!() is invoked before being able to configure the mocks in the tests.

I get errors similar to this:

** (Mix) Could not start application myapp: MyApp.Application.start(:normal, []) returned an error: shutdown: failed to start child: MyApp.TheWorker
    ** (EXIT) an exception was raised:
        ** (Mox.UnexpectedCallError) no expectation defined for MyApp.Service.get_api_response!/0 in process #PID<0.346.0> with args []
            (mox) lib/mox.ex:599: Mox.__dispatch__/4
            (londibot) lib/londibot/tfl/status_broker.ex:16: MyApp.TheWorker.start_link/0
            (stdlib) supervisor.erl:379: :supervisor.do_start_child_i/3
            (stdlib) supervisor.erl:365: :supervisor.do_start_child/2
            (stdlib) supervisor.erl:349: anonymous fn/3 in :supervisor.start_children/2
            (stdlib) supervisor.erl:1157: :supervisor.children_map/4
            (stdlib) supervisor.erl:315: :supervisor.init_children/2
            (stdlib) gen_server.erl:374: :gen_server.init_it/2

Sorry, I am not using Mox and cannot help You on this one.

How would you test that?

Following dependency rejection you would design the system to obtain the initial state before even attempting to start the GenServer - then there is no dependency that needs to be mocked out because the initial state is handed in as a plain value.

That’s what I thought initially – pass it throuh, and the Supervisors’ callback would look like this:

  def start(_type, _args) do
    import Supervisor.Spec, warn: false

    children = [
      {MyApp.TheWorker, @my_service.get_api_response!()},
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end

The issue is that it looks like mix first spins up the Application, then runs the test_helper.exs and lastly the tests. That means that since the mocks are set in the test_helper.exs, it doesn’t matter what I inject to the worker in the Supervisor callback, it will always be a mock whose get_api_response!/0 function doesn’t have an expectation set.

I think one solution could be to give it always an empty state as an initial state, I would however need to be able to tell the supervisor to feed it with a different state on restart, because I can’t afford to feed it an empty state every time it crashes. Is that somehow possible?

How about just not testing the genserver started by your supervision tree, but starting up additional ones with custom configuration just for your tests:

setup do
  {:ok, pid} = start_supervised({MyApp.TheWorker, mock_config()})
  {:ok, pid: pid}
end

test "whatever", %{pid: pid} do
  assert MyApp.TheWorker.do_stuff(pid)
end

--no-start fixes that

--no-start - does not start applications after compilation

So mix test without --no-start runs integration tests while mix test --no-start only runs the fast isolated tests.

The usual idiom would be to have another process, external to the worker, that holds onto that state and then supplies it to the worker when requested (maybe in the worker’s handle_continue?)

One possible sequence of events would look like:

• supervisor boots the “state fetcher/holder” process

• fetcher/holder boots up

• (optional) if in production, the fetcher/holder can make the get_api_response call from handle_continue. Otherwise, that call is deferred until the worker needs the data.

• supervisor starts the worker process

• worker process makes a blocking call from its handle_continue to the holder process to get the state

• in production, that call returns promptly once get_api_response has completed

• in test, that call would block (maybe with receive?) waiting for the go-ahead from the test setup code

• if the worker process crashes, the fetcher/holder can supply the already-loaded state to it when it restarts

That sounds like a fine solution. How would you code the logical branches around being in production or in test? I know using Mix.env/0 isn’t an option, since that isn’t available in production, and having an environment variable which holds the values :production or :test seems like a workaround. What’s idiomatic way of dealing with that?

Two things come to mind:
Unless you want the whole application to fail at startup if the initial state request fails, issue an Agent.cast after the start_link to initialize the Agent. Let the cast handler do the init. Since that cast will be first in the message queue, nothing will get to the Agent before it’s initialized. Also, in the init, you can use an Application env to control if it pulls that initial state. While you can’t use Mix.env, you can use a config that’s dependent on the Mix.env that’s set up at compile/release.