A passing build checks that code compiled. A UI acceptance check asks whether a person can use the feature in the states that matter. The checklist below is deliberately small enough to run on a real PR.
Choose the states before opening Preview
Start from the original request. List one normal path, one failure or empty path, and any permission or loading state that matters. Use realistic text lengths and data. This prevents a beautiful default screenshot from standing in for the whole feature. For a settings form, record three cases before testing: save a valid name and refresh, submit an empty name, and make the API fail while saving. Each case has a different visible result and a different place to inspect the request. A test account and disposable values keep the check repeatable without changing another person's profile.
| State | Action | Evidence to keep |
|---|---|---|
| Valid save | Enter a new name, save, then refresh | Confirmation, persisted value, successful request |
| Invalid input | Submit an empty name | Text error by the field and no unintended save |
| API failure | Make the save request fail in a test setup | Error state, editable form, failed request and response status |
Check more than one viewport
Open the local service in Canopy Preview and inspect desktop and a narrow mobile-sized viewport. Check wrapping, clipping, tap targets, forms, sticky controls, and scroll behavior. If the project has a design system, compare the change with existing components rather than judging one screen in isolation. Record the exact width and state for each finding.
Exercise interactions
Click or keyboard-activate the primary action. Try an invalid input and a successful one. Refresh when persistence matters. Tab through the form and confirm that focus remains visible; W3C's focus guidance explains why people need to locate the active control. When validation fails, identify the field and explain the error in text, as W3C's error-identification guidance requires. Check where focus goes after a failed save and whether the person can correct and retry without losing input. A screenshot of the initial state cannot prove any of these behaviors.
Look for runtime errors
Inspect the browser console and network activity for failed requests or unexpected statuses. Canopy Preview exposes these signals in its supported browser surface. A visible loading spinner can hide a failed API call; record the request and response status before asking an agent to alter CSS.
Tie the result back to the PR
Read the latest diff and checks after the visual pass. If an issue was fixed during review, repeat its reproduction on the newest commit. Automated screenshot comparisons can help with stable states, but rendering varies by environment and a snapshot does not replace interaction testing. The merge decision should state what was verified and what remains untested.
Copyable resources
Copyable UI acceptance checklist
Use on the latest PR commit and note any check that does not apply.
[ ] The normal path matches the request.
[ ] One failure or empty state is understandable.
[ ] Desktop and a narrow viewport were inspected at recorded widths.
[ ] Long text and realistic data do not clip or overlap.
[ ] Primary action works by pointer and keyboard; focus remains visible.
[ ] Loading, success, and error states were exercised where relevant.
[ ] Console and network failures were investigated.
[ ] The final PR diff and checks match the running result.
[ ] Remaining risks and unrun states are written down.Frequently asked questions
Does a screenshot test prove the UI works?
No. It compares rendered output for selected states. Interactions, network behavior, accessibility, and untested states still need checks.
What if the build passes but Preview is broken?
Treat the running result as a failed acceptance check. Inspect services, console, network, and the latest diff before asking for a focused fix.