testing-discipline

Testing discipline: tests as a spec and defining "done"

0. Acceptance and failure evidence (OPS §3)

Define observable acceptance and a suitable check before changing behavior. Accept user-reported failure evidence; reproduce when needed for diagnosis or regression, reusing applicable prior evidence. After a fix, exercise the affected behavior. State unavailable before-fix evidence explicitly. Preserve meaningful tests; keep a regression when a plausible recurring bug would fail it. Smoke probes and rendered UI interaction are also valid evidence.

1. Isolation and structure

1. NEVER TOUCH PROD STORE IN TESTS — use throwaway storage selected before import: env override, temporary path and isolated fixture. Do not connect to production merely to compare row counts.
2. CONTROL IMPORT SIDE EFFECTS — prefer explicit dependency injection or existing isolated fixtures; use a fresh import when a module actually captures storage at import time.
3. DOMAIN FIRST — exercise business rules directly; integration checks cover meaningful I/O boundaries. No arbitrary runtime target or mandatory framework bypass.
4. FAKE THE EDGES, NOT THE CORE — replace external Telegram/HTTP/API calls, not the business logic under test. Use a real temporary DB when persistence semantics are part of the behavior.

2. Names and boundaries

• TEST NAMES ARE THE SPEC — test_referral_no_self, test_crypto_idempotent — name = rule. pytest --collect-only reads like a product checklist. NOT test_1, test_works.
• PRODUCT RULES AS NAMED TESTS — the spec lives in tests: test_free_spent_first, test_cannot_buy_while_paid_remains. A new developer reads the tests = understands the product.
• ASSERT MATERIAL BOUNDARIES — choose plausible failure modes: zero/exhausted value, self-referral, double credit, empty input, overflow. No happy/edge/abuse quota for every function.
• WRITE THE ABUSE CASE WHEN YOU WRITE THE GROWTH CASE — referral/promo written with an anti-fraud test in the same PR.