I tend to avoid testing processes started by the applications supervision tree. I start a separate (set) of them manually and without global naming and pass the pid around to tests. This way I often get the ability to run tests async as well.

Just in case, here’s how I’d use start_supervised. Not sure if it addresses the problem.

Relevant bits:

• in test env the “real” pipeline is disabled in the config
• if config says the pipeline is disabled, it’s not added to the in the root supervisor, so that it doesn’t clash with any pipelines started in tests
• the pipeline callback module has default opts which can be overwritten in tests

I think I found one way of working with this based on this post.

First was to make the Broadway :name option overrideable by using Keyword.get/3 with a default value:

defmodule My.Pipeline do
    use Broadway

    def start_link(opts) do
        Broadway.start_link(__MODULE__,
        name: Keyword.get(opts, :name, __MODULE__),
        # ... etc ...
     )
   end
   # ... 
end

Then I can pass a unique :name option to my pipeline when I call start_supervised in my test:

test "start_link with custom options"
    {:ok, pid} = start_supervised({My.Pipeline,
                   [
                     queue_url: "fake-url",
                     producer: Broadway.DummyProducer,
                     # ... etc ...
                     name: :example
                   ]}
end

and it works equally well when I call start_link/1 directly:

{:ok, pid} = My.Pipeline.start_link(
                producer: Broadway.DummyProducer,
                queue_url: "fake-url",
              name: :something
              )

This works and I will probably use this method… the only downside I can see is that the regular built-in process in the application’s supervisor always starts… but we kinda just ignore it. That’s not a problem for my use case, however.

I think the docs for https://hexdocs.pm/ex_unit/master/ExUnit.Callbacks.html?#start_supervised/2 need some updating because they don’t really explain how to work with this common use case… I’m not sure what I did is even the proper way to work with that function… it just feels like a work-around more than anything else. Thoughts?

But beware that mix is not available in releases.

Sorry, misunderstood your problem, please ignore the suggestion below

I’d consider using

# config.exs

config :my, My.Pipe, enable: true # enable by default

# test.exs

config :my, My.Pipe, enable: false

# application.ex

  def start(_type, _args) do
    children = [
      if Application.get_env(:my, My.Pipe).enable do
        {My.Pipe, []}
      end
    ] |> Enum.reject(&is_nil/1)
    opts = [strategy: :one_for_one, name: My.Supervisor]
    Supervisor.start_link(children, opts)
  end

3 years later! spotted this post while dealing with some legacy code.

If you really need to restart a process that’s part of the app sup tree, say in the setup block of your test, you can do that with:

:ok = Supervisor.terminate_child(My.Supervisor, My.Pipe)
{:ok, _} = Supervisor.restart_child(My.Supervisor, My.Pipe)

And in order to make it work you’d need to name your Supervisor in the application start, like:

Supervisor.start_link(children, name: My.Supervisor)

Note: restarting child would use original child spec defined in your app. So if you’d like to override some options passed into a supervised module you’d need to not rely on actual options in the child spec, but on the configuration of your supervised module that’s pulled from the app configs. In the original example that topic started brought up that My.Pipe is getting started with empty options.

I saw that approach recommended by @sasajuric a while back and I would suggest you do that only if you have no other way and you just need to get things done quick. Of course, most likely you wouldn’t like to have such test running async.

But the approach with start_supervised that @LostKobrakai and @idi527 pointed out above is what is probably an ideal way of doing things