Four kinds of test, none with an AI in the loop

Real apps break in more than one way. The checkout flow stops working. A layout shifts and the invoice looks wrong. An endpoint starts returning 500 to logged-out users. A form loses its labels and a screen reader can't use it. Four failures, four kinds of test: end-to-end, visual, API, accessibility.

The newer AI testing tools are right that you shouldn't juggle four tools for this. Where some of them go wrong is how they unify it: a model in the loop at test time, "self-healing" each run. That trades one problem (many tools) for a worse one — every CI run now depends on an LLM's judgment, which is nondeterministic, costs money per run, and can quietly decide a real regression is fine and heal right past it.

Hover covers all four types too. None of them run a model.

The four types, each deterministic

• E2E — a recorded user flow. The agent walks checkout once through your real app; Hover crystallizes the exact clicks into a plain @playwright/test spec. Replay is the recording, not a re-interpretation.
• API — a request contract. Status code, response shape, the 401 a logged-out caller must get. Captured from the traffic your app already made, locked as assertions.
• Visual — a screenshot baseline via Playwright's toHaveScreenshot. A pixel diff against a committed image. A change is a change; no model decides whether the new pixels are "close enough."
• Accessibility — an axe-core scan. A rule engine checks WCAG: ARIA, contrast, keyboard reachability. It fails on serious and critical violations and names them.

Two of these are new in Hover; all four now live side by side under __vibe_tests__/{e2e,visual,api,a11y}/, and the Business Map marks each type so you can see, per business line, which kinds of test guard it.

Why "no AI at run time" is the whole point

An AI that heals your tests on every run is an AI that can hide a regression. If the login button moves and the model "adapts," great. If the login button moves because someone broke it, the model adapts to that too, and your test goes green on a broken app. You find out from a user.

A pixel diff can't rationalize. Axe can't be talked out of a contrast failure. A recorded click either lands on the control or it doesn't. That is the property you want from a test: it fails when the thing it guards is broken, and only then. AI is enormously useful for writing these tests — exploring your app, deciding what's worth locking. It has no business being the test.

How you get them

From the coding agent you already run: crystallize_visual_spec for the pages whose look matters, crystallize_a11y_spec for the pages that must stay accessible, alongside the E2E and API specs you already record. They land as plain Playwright in your repo and run in your CI — the a11y workflow installs @axe-core/playwright for you.

Four types. One suite you own. No model between your code and the verdict.

npm i -g @hover-dev/mcp@latest. More at gethover.dev.