How to have fixtures per test in Elixir?

Are you really testing at the “application” level? Because you cannot have multiple instances of an application running at the same time on the beam, so the requirement to be able to use async true would be moot.

If you’re not testing this at the application level, but at the process level I’d suggest passing the paths to the files in question as part of their startup, not having them depend on global state like the application environment.

For tests that will be modifying a fixture file, maybe you could make a copy of the fixture file in a temp dir and have the test use that (ExUnit has a @tmp_dir tag).

Are you really testing at the “application” level? Because you cannot have multiple instances of an application running at the same time on the beam, so the requirement to be able to use async true would be moot.

To be more precise, I launch a Supervisor wich then launches other processes. Think of it like a small GenServer application (with a supervisor) that you can use with iex -S mix.

It does not use phoenix, nor any major frameworks.

If you’re not testing this at the application level, but at the process level I’d suggest passing the paths to the files in question as part of their startup, not having them depend on global state like the application environment.

For tests that will be modifying a fixture file, maybe you could make a copy of the fixture file in a temp dir and have the test use that (ExUnit has a @tmp_dir tag).

To my knowledge, I could combine these two approaches. This would effectively result in the proposed solution I described, I would pass the files as arguments, and because I am doing it this way I can use the ExUnit setup callback to automatically generate temporary files and use them for each process.

As mentioned however, the (very heavy) downside of this approach, would be that it requires me to re-write a considerable portion of the application.

That’s the correct approach, the only thing you need to personally ensure is that this is idempotent, hence why using a temporary folder/files is the way to go.

That’s the correct approach, the only thing you need to personally ensure is that this is idempotent, hence why using a temporary folder/files is the way to go.

I understand that Ecto has a system under the hood where it creates mini-databases for each test running.

I am unsure on the details, but if it is true, Isn’t there a library that they use to this effect that could be applied to this scenario?

Yes, but with many processes involved you need to deal with Ecto.Adapters.SQL.Sandbox — Ecto SQL v3.12.1 as well. There’s a whole lot of machinery involved to make this injection of state happening (especially if it’s implicit). Caller lookups are the backbone of most mocking libraries in elixir as well.

Things will be way simpler if you don’t need the implicit part and explicitly provide configuration by passing it down the process tree / into processes. You can still do the following in your Application.start/2 callback to use config to provide those values when processes are started there.

children = [
   {Child, Application.get_env(…)}
]