designing-concurrent-testslisted

# Designing concurrent tests Build tests that stay correct under the real execution topology, not only when run alone on a quiet workstation. This skill owns isolation and reliability decisions; it does not choose which checks to run for a change. Read `.ledger.yml` for this project's focused-test command and the platforms CI covers. If the adapter is missing, say so and continue on the design questions — they do not depend on it. The rules below are stated as shapes, because they hold across runners and languages. [references/worked-example.md](references/worked-example.md) carries one fixture from five defects to correct in stages — a port the test picked, a predictable shared path, an environment mutation, sleeps standing in for readiness, and teardown that never awaits — and maps each defect back to the rule it violates. Read it before applying one of these rules for the first time; the restoration case in particular fails in a way no abstract statement conveys. ## Model the execution topology Assume these layers can overlap unless the active configuration proves otherwise: 1. Tests in one file. 2. Separate test files or worker processes. 3. Independent runner or check-lane processes in one job. 4. Different CI jobs whose runners share one host. **Process isolation does not isolate host ports, predictable filesystem paths, external services, databases, sockets, or inherited child processes.** For every acquired resource, identify five things: its owner, its atomic