How to have fixtures per test in Elixir?

Questions / Help
,
1

Background

I have an OTP application that reads data from json files. Depending on what these files have, the application may or may not modify them with new data.

Problem

The challenge here arrives when I am creating integration/e2e tests. I want to test the entire flow.

Normally I have my fixtures in tests/fixtures/my_file.json or something amongst those lines. I want my tests to run with async: true, so this creates a problem:

  • because my fixture file is static, different processes cannot read/write to the fixture file without causing race condition issues and messing up other tests
  • i also have to forceably reset the fixture file every time I run a test
  • becasue I have to use async: false this will cause my tests to be slow

Possible solution

I could in theory, create a fixture file per test running. I would have to spice the file name with a seed (like a random number) and then have the process know in advance which file it has to use.

This sounds to me like overly compex and would force me to have to rewrite a good chunk of the application, since I am only using the normal config/test.exs to tell where the files are located, and as far as I know this cannot be dynamic (at least not to the level I require):

config :store,
  products: Path.expand("#{__DIR__}/../apps/store/test/fixtures/products.json") |> Path.split(),
  setup: Path.expand("#{__DIR__}/../apps/store/test/fixtures/setup.json") |> Path.split(),

Questions

Given that the only solution I can think of seems rather complex, I would like to know if:

  • is there a standard way in Elixir to achieve dynamic fixtures for each test process?
  • are there any libraries that can help?
  • can you recommend any material (blogs, videos, etc) that deal with problems similar to this?

Ideally I am looking for something like bypass, which allows to async: true as well.

2

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.

1 Like
3

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).

2 Likes
4

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.

5

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.

6

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?

7

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(…)}
]
4 Likes