writing-testslisted

# Writing Tests Test code is production code. Same quality bar — naming, structure, immutability, file structure, security. The point of the test suite is to **find bugs**, not to confirm what the code already does. ## Read first (always) List `learnings/` and read every file relevant to the current task. Project-specific test framework choices, fixture conventions, flaky-test hotspots, or coverage carve-outs live there and override the defaults in this SKILL.md. If a learning conflicts with this file, **the learning wins** — mention it to the user. ## Tradeoff — when to apply, when to lighten up Apply the full discipline (pyramid, AAA, coverage gate, multi-platform matrix) for **production code**. Lighten the formality for one-off scripts, exploration, or examples under 30 lines — but even then, at least one happy-path test and one adversarial test. ## Pre-test analysis (mandatory) Before writing a single test: 1. **Identify the test framework.** Look for `pytest.ini` / `jest.config.*` / `vitest.config.*` / `*_test.go` / `build.gradle` test deps / `*.Tests.csproj` / `Cargo.toml [dev-dependencies]`. Use the framework already in the project. Do NOT introduce a new one. 2. **Identify the mocking library.** `unittest.mock` / `pytest-mock`, `jest.mock` / `vitest.mock` / `sinon` / `msw`, `Mockito`, `gomock` / `testify/mock`, `Moq` / `NSubstitute`. Use what's already there. 3. **Identify existing test patterns.** How are files named and organized? Are there factories, fixtu