Write Tests

<!-- Adapted for OFM from obra/superpowers test-driven-development (MIT), revision
8ca22dba9a94f28898bbce59f2537ff4d87c747d:
https://github.com/obra/superpowers/blob/8ca22dba9a94f28898bbce59f2537ff4d87c747d/skills/test-driven-development/SKILL.md
Copyright (c) 2025 Jesse Vincent; and po4yka/rust-skills rust-tdd (BSD-3-Clause), revision
9f4a3a4c904c1cbc507991b65397195ff724fa70:
https://github.com/po4yka/rust-skills/blob/9f4a3a4c904c1cbc507991b65397195ff724fa70/skills/rust-tdd/SKILL.md
Copyright (c) 2026 Nikita Pochaev. Full notices: ../../THIRD_PARTY_NOTICES.md.
GWT naming, OFM fixtures and persistence seam guidance are project-specific adaptations. -->

Write tests

Read the root Code quality rules and nearby tests first. Search canonical builders in ofm_core and use src/test-setup.ts on the frontend. Do not replace the project's runtime or install a whole testing framework. Tests pin the caller-visible contract; they do not mirror the implementation.

1. Scenarios before implementation

Write a named Given/When/Then table and carry it into the PR body:

Cover happy, edge, failure/abuse, user and AI routes for shared rules, and save/load. Mark routes inapplicable with a reason. When no written scenarios exist, state those for the touched routes before coding. Every applicable scenario gets one independently reported test; parameterize cases with the same outcome, split different outcomes. Preserve scope and discuss unclear acceptance criteria rather than inventing a larger story.

Use a plain sentence test name plus a Given/When/Then doc comment naming the scenario. Rust sentence names use snake_case in a same-file #[cfg(test)] module; frontend tests use a sentence in it(...) in co-located *.test.ts(x) files. For example:

/// Given a non-default budget, when the club is saved and reloaded, then the budget is preserved.
#[test]
fn a_saved_budget_survives_reload() { /* scenario assertions */ }

/** Given a rejected save, when the player submits, then the form shows the error. */
it("shows the error when saving fails", () => { /* scenario assertions */ });

Existing cross-crate tests belong at the owning integration layer. Command tests are in the root lib target.

2. Fixtures and assertions that discriminate

Use the smallest world containing the interaction, with real existing builders and seeded RNG. If generation/distribution is the behaviour, use the real generator rather than a hand-built population. Distinguish competing worlds: two competitions on one matchday, different wage units, non-default persisted values, a positive control for a negative assertion, and nonempty inputs before assertion loops. Expected values come from literals or an independent oracle, not the code under test. Preserve intentional engine mirrors and independent test computations.

Choose the cheapest layer that observes the claimed behaviour. Pure rules use unit tests; wiring uses the component/service or shared &StateManager seam. Read live state after mutations, not a returned clone alone. Persistence uses the real writer and a fresh DB connection/reader, with non-default values and absent-field old-save fixtures. Failure scenarios assert no partial mutation.

Frontend mocks retain the side effects the scenario needs. A controlled host feeds changed values back into props; a bare onChange={vi.fn()} proves only notification. Keep real hook behaviour for hook-order regressions (a hook-free i18n mock hides them). Prefer role/name or label queries; cover keyboard and focus. Service failure tests verify usable UI/error outcomes, not only a mock call.

3. RED, verified

Write the scenario test before production code. Name the predicted failed assertion and value, then run only that test and confirm its name and count appear:

cargo test --locked --manifest-path src-tauri/Cargo.toml -p <crate> '<scenario>' -- --exact '<module>::tests::<scenario>'
cargo test --locked --manifest-path src-tauri/Cargo.toml --lib '<scenario>'
# Add --features mcp to the lib command for an MCP scenario.
npm ci
npm test -- <co-located-test-file> -t '<scenario>'

These are templates: fill in a real target and use its full Rust path for --exact.

A pure refactor's characterization tests may pass initially: name that evidence characterization, not a fabricated red run. Do not delete prior work to restart TDD, commit stubs or change unrelated code.