Web Application Testing
Verify observable browser behavior with the repository's existing browser-test framework when possible. Prefer Playwright for new browser automation unless the project already standardizes on another tool.
Prepare
- Read repository instructions and discover documented install, server, seed, and test commands.
- Identify the smallest user journey that proves the requested behavior and the required test data or authentication state.
- Reuse an already-running server when safe. If starting one, use the project's command, wait for a deterministic readiness signal, record the process, and stop only the process you started.
- Never point destructive tests at production or shared data without explicit authorization.
Reconnaissance
Inspect the rendered accessibility tree or DOM, a screenshot, browser console, and failed network requests before guessing selectors or causes. Wait for a page-specific condition such as a visible heading, URL transition, API response, or loading indicator removal; do not rely on networkidle when background traffic can continue indefinitely.
Prefer selectors in this order:
- accessible role and name;
- associated label or visible text;
- stable project-owned test ID;
- CSS selectors only when no semantic handle exists.
Test
- Exercise the behavior as a user would, including meaningful success, validation, authorization, loading, empty, and failure states.
- Assert outcomes and state transitions, not implementation details or arbitrary time delays.
- Capture console exceptions, unhandled promise rejections, relevant failed requests, and screenshots or traces for failures.
- Check keyboard access and focus behavior for changed interactive flows.
- Cover representative narrow and wide viewports when layout is material.
- Add a regression test for a confirmed bug when it can run deterministically.
Run the focused test first, then the relevant browser suite and supporting lint/type checks in proportion to the change. Treat flaky behavior as a finding to investigate, not a reason to add sleeps or retries blindly.
Report
Return the tested URL/environment, commands, scenarios, pass/fail results, evidence paths, fixes made if requested, skipped coverage, and residual risk. Do not claim a flow works if a required service or credential prevented verification.
1---2name: webapp-testing3description: Test a local or preview web app in a real browser for user flows, rendered state, accessibility, console or network errors, and responsive layouts.4license: Apache-2.0; see ../LICENSES/Apache-2.0.txt and ../THIRD_PARTY_NO5---67# Web Application Testing89Verify observable browser behavior with the repository's existing browser-test framework when possible. Prefer Playwright for new browser automation unless the project already standardizes on another tool.1011## Prepare12131. Read repository instructions and discover documented install, server, seed, and test commands.142. Identify the smallest user journey that proves the requested behavior and the required test data or authentication state.153. Reuse an already-running server when safe. If starting one, use the project's command, wait for a deterministic readiness signal, record the process, and stop only the process you started.164. Never point destructive tests at production or shared data without explicit authorization.1718## Reconnaissance1920Inspect the rendered accessibility tree or DOM, a screenshot, browser console, and failed network requests before guessing selectors or causes. Wait for a page-specific condition such as a visible heading, URL transition, API response, or loading indicator removal; do not rely on `networkidle` when background traffic can continue indefinitely.2122Prefer selectors in this order:23241. accessible role and name;252. associated label or visible text;263. stable project-owned test ID;274. CSS selectors only when no semantic handle exists.2829## Test3031- Exercise the behavior as a user would, including meaningful success, validation, authorization, loading, empty, and failure states.32- Assert outcomes and state transitions, not implementation details or arbitrary time delays.33- Capture console exceptions, unhandled promise rejections, relevant failed requests, and screenshots or traces for failures.34- Check keyboard access and focus behavior for changed interactive flows.35- Cover representative narrow and wide viewports when layout is material.36- Add a regression test for a confirmed bug when it can run deterministically.3738Run the focused test first, then the relevant browser suite and supporting lint/type checks in proportion to the change. Treat flaky behavior as a finding to investigate, not a reason to add sleeps or retries blindly.3940## Report4142Return the tested URL/environment, commands, scenarios, pass/fail results, evidence paths, fixes made if requested, skipped coverage, and residual risk. Do not claim a flow works if a required service or credential prevented verification.
egeetas