Basics
This check is disabled by default.
Learn how to enable it via .credo.exs.
This check has a base priority of high and works with any version of Elixir.
Explanation
A test file declared async: true does not change application config.
ExUnit's scheduling is an invariant a suite comes to lean on: every async: true module
runs first, then the sync modules run serially — so an async test may safely read config
that only sync files ever mutate.
Application env is one table for the whole VM, and the database sandbox does not reach it. A
put_env in an async file is therefore visible to every test running beside it for as long
as the override lasts, and the test that fails is whichever one happened to read the key in
that window — never the file that set it. SyncTestBlocker holds the other half of this rule
(a sync file says why it is sync); this one holds the half that breaks other files.
It flags, inside a module whose use carries async: true, a call to
Application.put_env, put_all_env or delete_env, or to one of the TestEnv helpers
(test/support/test_env.ex: put_app_env, merge_app_env, delete_app_env) — qualified
or imported, since the helper restores the value afterwards but cannot make the override
private to its test. The remedy is one of two: pass the value to the code under test as an
option, or make the file async: false and name the key in its header.
What it cannot see is a mutation one call away: a test/support stub that calls
Application.put_env for its caller reads as an ordinary call here. A new async file that
uses one is a review finding.
Check-Specific Parameters
There are no specific parameters for this check.
General Parameters
Like with all checks, general params can be applied.
Parameters can be configured via the .credo.exs config file.