View Source ExUnit formatter contract

ExUnit Atlas was initially verified on Elixir 1.14.4 and OTP 25. It relies on the public ExUnit.Formatter contract rather than ExUnit runner internals.

Observed lifecycle

An ExUnit formatter is a GenServer which receives these events through casts:

  1. suite_started
  2. module_started
  3. test_started
  4. test_finished
  5. module_finished
  6. suite_finished

The test_started and test_finished events contain an ExUnit.Test structure. Atlas uses the following fields:

  • name
  • module
  • state
  • time
  • tags.file
  • tags.line
  • tags.describe

Captured logs are available through test.logs in the verified runtime, but they are deliberately excluded from the report. Schema version 2 uses explicit show items instead, avoiding unrelated Logger noise and implicit capture.

Test ownership

The formatter contract does not expose the test process PID. Atlas therefore does not use a PID as the identity of a test and does not inspect ExUnit's process dictionary.

Instead, use ExUnitAtlas registers a setup callback. The callback executes in the test process and derives the internal key:

{context.module, context.test}

The formatter derives the equivalent key from the completed test:

{test.module, test.name}

This key is internal and never appears in the public report.

Concurrency verification

The integration fixture runs two separate async: true modules with the same human-readable test name. A barrier forces their execution to overlap, and their Atlas items are deliberately interleaved.

The fixture is repeated 50 times. Every run must produce:

Test A → A1, A2
Test B → B1, B2

No item may cross owners, disappear, or change order. This test guards the central concurrency assumption behind Atlas.