Arrange-Act-Assert (AAA) skeleton — framework-agnostic.

Every test should map cleanly to three phases. If a test has more than one
"Act", it is testing more than one behavior — split it.

  TEST: <behavior described in plain language>

    ARRANGE
      - Build the smallest input that exercises the behavior
      - Set up mocks/stubs for external boundaries only
      - Establish known starting state (fixtures, seeded data)

    ACT
      - Invoke exactly ONE unit of work (the function/method under test)
      - Capture the return value or the resulting state

    ASSERT
      - One logical assertion about the outcome
      - Assert on observable behavior (return value, emitted event,
        persisted record, rendered output) — NOT on internal calls
        unless the interaction IS the contract (e.g. "publishes event")

    CLEANUP (if needed)
      - Restore mocks, clear timers, remove temp files, roll back tx


Naming pattern (pick one and stay consistent with the repo):
  - "should <expected behavior> when <condition>"
  - "<method> returns <X> given <Y>"
  - "<scenario>_<expected_result>"   (snake_case repos)


Anti-patterns to avoid:
  - Asserting implementation details (spy.calledWith on an internal helper)
  - Multiple unrelated acts/asserts in one test
  - Shared mutable state between tests (breaks isolation/order independence)
  - Sleeping for timing — fake the clock instead
  - Snapshotting volatile output (timestamps, ids) without normalization
