Sunbytes — Test React behaviour

For React components and custom hooks that already exist. If the user is writing tests before the implementation, stop and use tdd. For non-React .ts modules, use sb-write-vitest. Always load sb-react alongside this skill.

File conventions

• One test file per component, beside the source: Counter.tsx → Counter.test.tsx.
• Use *.test.tsx, never *.spec.*. .spec. is reserved for integration/e2e.
• Custom hooks: useCart.ts → useCart.test.ts (use renderHook).
• One top-level describe per component or hook, named after it: describe('<Counter>', ...) or describe('useCart', ...).

What to test — and what not to

• Test behaviour, not implementation. What the user sees on screen and what happens when they interact. Survive an internal refactor that preserves observable behaviour.
• Do not assert on internal state, hook return values from inside a component, prop spreading, class names, or DOM structure.
• Do not snapshot whole components — snapshots invite churn and hide regressions. Use inline snapshots only for small, stable serialised output.
• Query by accessibility. Prefer getByRole(name), getByLabelText, getByText — in that order. getByTestId is a last resort and a smell.
• userEvent, not fireEvent. userEvent simulates real keyboard/pointer behaviour (focus, bubbling, debounce-friendly). Always await it.