fireproofsocks
I’ve got a simple app that starts up a supervised Broadway pipeline. This is fine for regular use, but it makes testing difficult:
def start(_type, _args) do
children = [{My.Pipe, []}]
opts = [strategy: :one_for_one, name: My.Supervisor]
Supervisor.start_link(children, opts)
end
I’m wondering if there’s a way to re-start the process with different options specifically for testing? I would like to send some different options to the start_link/1 function specifically to help override things for testing.
Is this possible? Or should I rely instead on using Application.put_env/3 to modify settings at (testing) runtime?
Trending in Questions
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
Hi everyone,
I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding.
I sta...
New
Hello,
I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
So my question is quite simple and i have found no conclusive answer on forum, google or AI.
Should we use :erlang.float for Integer to ...
New
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
I’m new to elixir and just tried to install the elixirLS extension for VScode(ium) and it is throwing some errors that I would like help ...
New
Other Trending Topics
Edit: 2026 May 15 - This post is archived.
Mob is alive!!
Main docs: mob v0.7.11 — Documentation
A bit of explanation for the slightly c...
New
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex










Showing Posts 11 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
alecnmk
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:
And in order to make it work you’d need to name your Supervisor in the application start, like:
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.Pipeis 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_supervisedthat @LostKobrakai and @idi527 pointed out above is what is probably an ideal way of doing thingsidi527
Just in case, here’s how I’d use
start_supervised. Not sure if it addresses the problem.Relevant bits:
fireproofsocks
I think I found one way of working with this based on this post.
First was to make the Broadway
:nameoption overrideable by usingKeyword.get/3with a default value:Then I can pass a unique
:nameoption to my pipeline when I callstart_supervisedin my test:and it works equally well when I call
start_link/1directly: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?
fireproofsocks
That’s the route I’m going down… but I still don’t see room for overrides when the process has already started BEFORE I execute my test code.
For example, if I want to override a callback that would normally query an external API with a mock callback that mimics a bad response from the API, I can do that in an individual function by using
Application.get_env/put_env/3… but when those options need to be overridden inside thestart_link/1implementation and the process is already started… there isn’t a way to override the behavior. Even making use ofBroadway.DummyProduceris pretty difficult when the process has already been started.So I feel like I’m running around in circles. It feels like there is a way to do this, I just can’t make enough sense of the docs to pull the rabbit out of the hat.
Qqwy
A clean way to do this is to just bake the possibility to switch to the special testing settings into your code.
One possibility would be to add one (or a few) optional arguments that can override the ‘default’ settings that are used.
The advantage on this over relying on
Application.get_env/put_envis that it is completely separate between test-cases (it is ‘functionally pure’). This helps reasoning about the tests, but also e.g. allows your tests to run concurrently.fireproofsocks
That would work in a pinch, but it pegs all options to the environment, and the tests need to vary the options in order to fully test the results…
fireproofsocks
I’m not sure if I follow how you’d do this… when I try to (re)start the Broadway pipeline for testing, e.g.
I get an error:
Likewise, I can’t figure out the syntax required to make the
start_supervisedoption work.Returns
{:error, {{:EXIT, {:undef, ...Same for:
Am I close?
idi527
I’m not sure how well known it is, but there’s start_supervised/2 for the approach described by @LostKobrakai.
LostKobrakai
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.
idi527
But beware that mix is not available in releases.
Sorry, misunderstood your problem, please ignore the suggestion below
I’d consider using