writing-automated-testslisted

# Writing automated tests Unit and integration tests only — E2E/browser/user-journey work belongs to [testing-with-playwright](../testing-with-playwright/SKILL.md); a request naming Playwright explicitly always routes there, never absorbed here. See [enforcing-safety-baseline](../enforcing-safety-baseline/SKILL.md): a test result is only real once it actually ran in this session. ## Workflow 1. **Discover the test stack.** Read package manifests, test config, existing test directories, naming conventions, fixtures/factories/helpers/mocks, and CI test scripts. Detect the framework in use (Jest, Vitest, Pytest, PHPUnit, JUnit, etc.) — never assume, and never introduce a second test framework alongside one that already exists. 2. **Identify the behavior under test**: what must keep working, inputs/outputs, boundaries, dependencies, permission/tenant behavior, and — for a bug fix — the actual failure being fixed. Don't write a test that just mirrors the implementation line-by-line. 3. **Choose the test level.** Unit: behavior isolates cleanly with small, controllable dependencies. Integration: the behavior that matters depends on real collaboration across a boundary — a DB adapter, an HTTP boundary, a queue, a repository, serialization/persistence. Never call a test "integration" when it mocks every boundary that would make it one. E2E/browser flows redirect to `testing-with-playwright` instead of being written here. 4. **Do a test-gap analysis** before adding anything: happy