Fl4m3Ph03n1x
How to have fixtures per test in Elixir?
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: falsethis 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.
Marked As Solved
LostKobrakai
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(…)}
]
Also Liked
eahanson
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).
LostKobrakai
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.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"