writing-tests

# Writing Tests ## Core Principle Tests prove behavior works. A test that can't fail is worthless. A test that tests mocks instead of real code is theater. ## Discover the Test Setup First Before writing the first test, establish what this repository actually runs. Reaching for a default command is how a suite goes green locally and red in CI. - **Runner and its config**: whichever manifest and test-config file the project's ecosystem uses. Framework-specific detail belongs to the language skills listed under Integration. - **The checked-in wrapper over any global binary.** A globally installed binary routinely resolves to a different version than the project pins, so prefer the project-local invocation (`uv run pytest` over bare `pytest`, `vendor/bin/phpunit` over `phpunit`). - **Focused vs. full invocation**: the edit loop needs to run one file or one test; completion needs the whole suite. Learn both forms. - **Where tests live and how neighbouring test files are named** -- match the existing convention rather than importing one. - **The command CI gates on** (`.github/workflows/*.yml`). When CI and the README disagree, CI is authoritative. ## Writing Good Tests ### One behavior per test Each test should verify exactly one thing. If the test name needs "and" in it, split it into two tests. ``` Good: "creates user with valid email" Good: "rejects user with duplicate email" Bad: "creates user and sends welcome email and updates counter" ``` ### Derive test case...