Organisation & Scope
How the tests/ tree is structured, suites as folders, steering files, and how their scope chains at run time.
Two rules build the whole structure: a file is a test case, a folder is a suite, and suites nest, so the tree mirrors your test structure plan:
| Entry | What it is |
|---|---|
login_test.md | A single test case, the file name is the test's name in runs and reports |
user_matrix.csv | Also test cases, one per row; every format sits side by side in the same tree |
checkout/ | A suite: its cases run together, framed by the suite's own setup.md and under its own rules.md in addition to the outer one. Nest deeper for sub-suites |
user-management/ | A sibling suite, no steering files of its own, so only the root ones apply. Suites are independent: a failing checkout/setup.md never touches it |
rules.md, setup.md, teardown.md | Steering files, allowed at every level, each scopes to its folder and everything below |
Scope
The steering files reach downward, never sideways. In the tree above,
tests/checkout/pay_with_card.md runs framed by tests/setup.md and
tests/checkout/setup.md, and rules accumulate: the root
tests/rules.md applies to every phase, tests/checkout/rules.md adds the
suite's own rules on top, but only inside tests/checkout/.
tests/user-management/create_user.md gets only the root files. Setups run
top-down, teardowns bottom-up, pressing Run on the checkout suite:
A failing setup blocks exactly the tests below it; sibling suites are unaffected. Any level can be a run target: one file, one suite, or the whole tree, folder structure is also your run granularity.