socketdev Testing Web Interfaces
Choose the lowest layer that proves the user-visible behavior, then add a browser test when interaction, layout, navigation, or rendering integration is the risk.
Workflow
- Read test-layering.md and state the behavior and failure mode before choosing a tool.
- Write focused Vitest coverage for deterministic component/state behavior.
- Use the repository’s browser-test setup for real navigation, keyboard behavior, responsive state, and browser APIs. Do not create a competing runner.
- For a locally served page, start the repository's existing development command through the
package.json script that launches it through
portless. Test the generated HTTPS.localhostURL; do not hard-code a port or create another server path. - Capture rendered output through rendering-chromium-to-png when visual correctness is material.
- Run the canonical repository test and coverage commands before handoff.
Boundaries
- Test user-observable outcomes rather than implementation details.
- Keep browser tests independent and avoid fixed sleeps; wait for meaningful UI state.
- Route design review findings to reviewing-web-interfaces.
Design Cluster
Use designing-interfaces for the intended visual direction, improving-web-interfaces for component changes, reviewing-web-interfaces for rendered evidence, extracting-design-systems for shared patterns, and optimizing-react-interfaces when the regression is performance-sensitive.
References
- Test-layer selection and source map