App Testing
Public Made by Adomby adom
Build a browser-driven end-to-end test suite that RENDERS your web app in real Chrome, clicks every control, fails on any page error, and gates on interaction coverage so a new untested button turns the suite red.
App Testing
Build a browser-driven end-to-end test suite for a web app that actually renders the page in real Chrome, clicks every control, and fails on any page error — plus an interaction-coverage gate that turns the suite red when a new control ships without a test.
Why
A test that reads your HTML as a string can go fully green while the app cannot
render. This skill's suites can't: they drive a real browser, so a handler that
throws on card-open, a dangling getElementById, or a modal that never appears
is caught — not shipped.
What you get
- The page-error gate — every driven page fails the run on any uncaught exception or console error.
- Flow tests — open a screen, drive a journey, assert the behavior (message sends, list numbers 1·2·3, zero horizontal overflow), not that an element merely exists.
- The coverage gate — a manifest of every control; a runtime pass
enumerates what actually renders (via
Element.checkVisibility, which walks ancestor opacity) and fails on any orphan — a live control with no test. Forget to test a button and the suite goes red. - A self-contained harness — spawns the app's own server on a scratch port with seeded, deterministic state, drives in-container Chrome, and cleans up.
- A viewport matrix — a real phone width (393px) and desktop, with hover/pointer media-feature emulation, asserting the page never scrolls sideways.
Use it
Ask your agent things like:
- "Add an end-to-end test suite that clicks through every control in my web app."
- "Make the tests fail if I add a button with no test for it."
- "My tests are green but the app is broken — why, and how do I catch it?"
The skill walks the agent through the harness, the gates, the manifest, the viewport matrix, and the pitfalls that make UI tests lie.
# App Testing
Build a browser-driven **end-to-end test suite** for a web app that actually
**renders** the page in real Chrome, clicks every control, and **fails on any
page error** — plus an **interaction-coverage gate** that turns the suite red
when a new control ships without a test.
## Why
A test that reads your HTML as a string can go fully green while the app cannot
render. This skill's suites can't: they drive a real browser, so a handler that
throws on card-open, a dangling `getElementById`, or a modal that never appears
is caught — not shipped.
## What you get
- **The page-error gate** — every driven page fails the run on any uncaught
exception or console error.
- **Flow tests** — open a screen, drive a journey, assert the *behavior*
(message sends, list numbers 1·2·3, zero horizontal overflow), not that an
element merely exists.
- **The coverage gate** — a manifest of every control; a runtime pass
enumerates what actually renders (via `Element.checkVisibility`, which walks
ancestor opacity) and fails on any **orphan** — a live control with no test.
Forget to test a button and the suite goes red.
- **A self-contained harness** — spawns the app's own server on a scratch port
with seeded, deterministic state, drives in-container Chrome, and cleans up.
- **A viewport matrix** — a real phone width (393px) and desktop, with
hover/pointer media-feature emulation, asserting the page never scrolls
sideways.
## Use it
Ask your agent things like:
- "Add an end-to-end test suite that clicks through every control in my web app."
- "Make the tests fail if I add a button with no test for it."
- "My tests are green but the app is broken — why, and how do I catch it?"
The skill walks the agent through the harness, the gates, the manifest, the
viewport matrix, and the pitfalls that make UI tests lie.