component-testing

# Component Testing (React Testing Library) ## Overview A component test that queries by `data-testid` or asserts on internal state proves the implementation didn't change, not that the component works for a user. React Testing Library tests must exercise the component the way a user (and a screen reader) does: find things by role/label/text, interact with them, and assert on what actually rendered. **Core principle:** Test behavior, not implementation. If a refactor that keeps the same user-facing behavior breaks the test, the test is coupled to the wrong thing. ## Rules - **Query priority: `byRole` first.** Prefer `getByRole` (with `{ name: ... }`) over `byLabelText`/`byText`, and both over `byTestId`. `byTestId` is a last resort for a node with no accessible role or text — reach for it only when nothing else identifies the element, and treat its presence as a smell worth a follow-up (usually a missing label/role, per accessibility-basics). - **`user-event` over `fireEvent`.** `fireEvent.click` fires one DOM event; `userEvent.click` simulates the real sequence of events a browser produces (focus, pointer, keyboard) and catches bugs `fireEvent` cannot (e.g. a control that only works because it happens to be focused). Always `await userEvent.setup()` / `await user.click(...)`. - **Assert on accessible, user-visible output.** Check rendered text, roles, `aria-*` state (`aria-expanded`, `aria-invalid`, `aria-disabled`), and focus — not component internals, prop values, or ...