Testing

Overview

Writing tests: unit/integration/e2e plus data-pipeline, ML, and infrastructure domains. This file owns test-double taxonomy, AAA, and framework patterns. For pyramid ratios, coverage targets, risk prioritization, and flaky-test diagnosis, see loom-test-strategy; for browser/Playwright/Cypress, see loom-e2e-testing.

Workflow

1. Map the unit — public interface, dependencies/side effects, invariants, error paths, boundary values.
2. Pick the altitude — unit for logic/branches; integration for real collaborators (DB, HTTP) at a boundary; e2e for user journeys. Push detail down the pyramid (loom-test-strategy).
3. Write failing test first when practical (TDD red→green→refactor): a red test proves the test actually exercises the code; a test that never failed asserts nothing.
4. Arrange-Act-Assert, one logical assertion per test, deterministic inputs.

AAA and naming

• Arrange state/doubles → Act (one call to the unit) → Assert outcome. Blank-line separate the three; more than one Act means split the test.
• Name test_<unit>_<scenario>_<expected> — e.g. test_cart_add_duplicate_increases_quantity. The name is the spec; a failing name should tell you what broke without reading the body.
• One logical assert per test. Multiple physical asserts on one behavior are fine (status, then body); asserting two unrelated behaviors is "assertion roulette" — the first failure masks the rest. Prefer one composite assert (assert_eq!(got, expected_struct)) over many field asserts.