View Source Product hypothesis result
The original spike tested one product hypothesis:
Adding named
stepandcheckblocks to regular ExUnit tests can produce a readable map of guaranteed behavior without weakening ExUnit's concurrency or failure semantics.
The technical path was verified by automated unit and integration tests. The product evaluation used a real sales business-logic test file and a failing integration fixture.
| Question | Result | Observation |
|---|---|---|
| Are business rules understandable without opening test bodies? | Yes | Named checks expose the all, only_cash, only_cashless, and disabled rules directly. |
Is the distinction between step and check useful? | Yes, with a caveat | It works well when one setup produces multiple contrasting guarantees. |
| Is the failure location clear? | Yes | A failed report contains the check name, assertion message, and user stacktrace frame. |
| Is the report more useful than a list of test names? | Yes | One scenario can expose several distinct guarantees, especially for cash versus cashless behavior. |
| Does the DSL force artificial fragmentation? | Sometimes | Wrapping trivial map literals can be noisy; only meaningful preparation or actions should become steps. |
Was show/2 necessary? | No | Names and checks were sufficient for the tested business logic. |
Decision
The core hypothesis is considered validated for the tested domain. The static HTML report was added because the JSON offered useful information beyond test names alone.
The main product guidance derived from dogfooding is:
Do not add a
stepmerely to make every scenario contain one. Use steps for meaningful actions or setup, and use checks to state guarantees.
Future features should preserve that small surface instead of turning Atlas into an assertion framework or general observability system.