Interaction Test Harness
Test the app the way a person uses it, through real clicks, keys, and focus.
What it adds
A test setup that drives menus, dialogs, forms, and navigation through genuine user interactions and asserts on what the user can see.
What your agent is told to do
5
What your agent is told to do
5-
1
Find elements the way a user finds them — by their visible label, their role, and their accessible name — rather than by class names or internal test hooks, so a test breaks when the interface becomes unusable and not when a wrapper is renamed.
-
2
Drive each interaction through both pointer and keyboard where both are supported, and assert on where focus ends up as well as on what the screen shows.
-
3
Assert on the visible outcome and wait for it to appear, rather than sleeping for a fixed interval and hoping. A timer-based wait is either slow on every run or flaky on a loaded machine.
-
4
Cover interruptions and repeats explicitly: a dialog closed while its request is still in flight, a submit button pressed twice, a menu reopened before its close animation finishes, a navigation triggered mid-save.
-
5
Rendered appearance is covered by Visual Regression Testing and accessibility rule checking by the Accessibility Test Suite; this brief owns behaviour under interaction. Do not assert on pixel positions or repeat contrast checks here.
Edge cases it handles
7
Edge cases it handles
7- Selectors tied to implementation detail pass while the interface is broken and fail while it is fine, so a test that finds a control by its internal identifier is testing the wrong thing entirely.
- A flow that works with a mouse can be unreachable by keyboard, and a suite that only clicks will never notice — every interaction test needs to say whether it exercised pointer, keyboard, or both.
- Fixed sleeps are the main source of flake; the harness must wait for the element or the text the user would wait for, with a bounded timeout that fails loudly rather than silently passing.
- Repeated and interrupted actions are where real defects live — double submits, a dialog dismissed before its response returns, a rapid second click on a control that was meant to disable itself — and none of these appear in a happy-path script.
- Asserting on an element that is in the DOM but visually hidden or covered by an overlay produces a passing test for something the user cannot reach; check visibility, not presence.
- Tests that share state through a common fixture will pass in isolation and fail when run in a different order, so each test must set up and tear down its own data.
- Animations and transitions make elements briefly present but not yet interactive; either disable them under test or wait for the settled state rather than the first appearance.
Definition of done
8
Definition of done
8- Tests locate controls by visible text, role, or accessible name, and no test depends on a class name or internal identifier.
- Each covered flow is exercised by pointer and by keyboard, with focus position asserted at the key transitions.
- No test contains a fixed sleep; every wait is for a visible outcome with a bounded timeout.
- Double submission, interruption mid-request, and rapid repeat interactions each have a test.
- Assertions confirm the element is genuinely visible and reachable, not merely present in the DOM.
- The suite passes when tests are run in a randomised order.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Visual Regression Testing
Visual Regression Testing
Catch unintended visual changes before they reach users, not after.
What it does
An automated comparison of rendered screenshots against approved baselines, run on every change.
How it works
- 1 Identify the surfaces where a silent visual change would actually hurt — the shared components, the pricing table, the checkout, the dashboard — and capture those rather than screenshotting every route in the app.
- 2 Freeze everything that varies between runs before capturing: load fonts and wait for them, fix the clock to a known instant, disable animations and transitions, and render from seeded fixtures rather than live data.
- 3 Capture each surface in every theme and at every viewport the app claims to support, and label each capture with that combination so a diff says exactly which one moved.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/visual-regression-testing
UX Edge-Case Checklist
UX Edge-Case Checklist
Make every UI feature state what it does when things go wrong before it counts as done.
What it does
A required list of non-happy-path behaviours — failure, empty, loading, offline, permission, mobile, and accessibility — answered per feature.
How it works
- 1 Attach the checklist to the point where work is proposed and to the point where it is reviewed, so the answers exist before the feature is built rather than being reconstructed afterwards.
- 2 Require a concrete answer for each category: what the empty state says and what it offers, what appears while data is loading, what the user sees when the request fails, and what a user without permission gets instead.
- 3 Make each answer an outcome someone else could verify. A feature that says errors are handled has not answered; one that says a failed save keeps the form open with the values intact and a retry has.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/ux-edge-case-checklist
Theme Acceptance Criteria
Theme Acceptance Criteria
Set the bar every theme has to clear before it ships to anyone.
What it does
A release gate for light, dark, branded, and customer-supplied themes, covering contrast, first paint, tokens, and print.
How it works
- 1 Write the criteria against the theme layer, not against individual screens. The question is whether a set of token values is fit to ship, and the answer should not require walking every page by hand.
- 2 Require measured contrast for text, icons, borders, focus rings, and disabled content in every interactive state — resting, hover, focus, active, and selected — because a palette that passes at rest often fails on hover.
- 3 Cover the surfaces that sit outside the component library: chart series and their gridlines, map and image overlays, embedded documents, illustrations, and any asset shipped as a fixed-colour file that will not follow the theme.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/theme-acceptance-criteria
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.