test-strategylisted

# Behavioral Test Strategy ## Current Project State - Test runner: !`node -e "try{const p=require('./package.json');console.log(Object.keys(p.devDependencies||{}).filter(d=>['jest','vitest','mocha','playwright','cypress'].some(t=>d.includes(t))).join(', ')||'none detected')}catch{console.log('no package.json')}" 2>/dev/null` - Test script: !`node -e "try{console.log(require('./package.json').scripts?.test||'none')}catch{console.log('none')}" 2>/dev/null` Test observable behavior through stable public interfaces. Coverage percentages and test-file counts are signals, not the goal. ## When This Activates - Writing a new function or module - Creating a React component - Building an API endpoint or route handler - Implementing a custom hook - Writing utility/helper functions ## Choose the seam first Before writing a test, name: - **Behavior** — what a user or caller can observe - **Public interface** — the supported way they exercise it - **Seam** — the highest stable interface where the behavior is deterministic - **Oracle** — the independent source of the expected result Prefer the highest seam that is still fast and deterministic: 1. Existing integration/module interface 2. HTTP/CLI/public package interface 3. Browser flow for critical user behavior 4. Unit-level seam only when the logic is genuinely isolated Do not create a seam solely for mocking. One adapter is usually a hypothetical abstraction; introduce a seam when behavior actually varies or needs isolation.