What test drift detection actually catches

A test suite only knows about a page the moment it runs against it. Between runs, the page it's actually testing can change underneath it — and nothing tells you until the suite happens to hit that path again. Drift detection is the piece that watches in between.

The gap a suite can't see

Say your nightly run is green Monday through Thursday. Wednesday afternoon, someone ships a change to the checkout page — a data-testid gets dropped during a refactor, or a button that used to say "Continue" now says "Next step." Nobody runs the payment test by hand to check. Thursday night, the suite runs, hits that page, and fails.

What actually happened is simpler than the failure makes it look: the page changed Wednesday afternoon. The suite just didn't have a reason to look until its next scheduled run, almost two days later. That gap — between a change shipping and a test noticing — is where drift lives, and it's the same gap whether the suite runs nightly or on every commit. Running tests more often narrows the window; it doesn't watch the window.

How Guardian watches it

Guardian doesn't run your tests to check for drift. It walks the pages your tests already depend on — the ones you recorded — and compares what it finds against the DOM snapshot captured at record time. That's a much lighter operation than executing a full test, which is what makes running it hourly, or on every deploy, practical instead of expensive.

1. Walk the recorded pages

   Not a crawl of the whole site — specifically the URLs your existing test cases touch, since those are the only pages a change to actually matters for right now.

2. Get past the login screen

   Most of what's worth watching sits behind authentication. Guardian replays a recorded login segment to reach those pages, so coverage doesn't stop at the sign-in form.

3. Compare against the record-time snapshot

   The live DOM is diffed against what was captured when the test was recorded — the same snapshot the healing cascade uses, so drift detection and self-healing are reading from one source of truth, not two that can disagree.

4. Classify and roll up by page, not by test

   A shared header or nav component can back thirty different test cases. Guardian reports the one thing that actually changed, once, against the page — then rolls it up to a risk level for every test that depends on it, instead of surfacing thirty near-identical alerts for a single edit.

What a finding actually looks like

Every drift event gets one of three ratings, based on whether the thing that changed is what your test actually depends on to pass:

What drift detection will not tell you

A scan is only as useful as your trust in what it leaves out, so the limits are worth stating as plainly as the findings.

• It compares structure, not pixels.A colour, a font or a margin changing is not drift. Screenshot comparison flags every rendering difference between machines and browsers, and a finding nobody believes stops being read.
• It does not check behaviour.A checkout page that looks exactly as recorded but totals the basket wrongly is not drift. That is what the test’s own assertions are for, and a green scan says nothing about them.
• It only watches what was recorded.A page no test visits has no snapshot to compare against, so a new screen is invisible to it until somebody records a test that reaches it.
• It reaches what the service can reach.Hosted scans open public addresses. An application on localhost or an internal network needs the self-hosted deployment.

Guardian is on Solo for up to five URLs, and on Team and Enterprise for every URL you record. Recording the tests it watches is on every plan, free included.

Three things this changes

• Proactive, not reactive.You find out a test id disappeared from the payment page Tuesday morning — not when the nightly run goes red Friday, mixed in among whatever else failed that night.
• Scoped by page, not by test.One navigation rewrite is one finding, pointed at the page that changed, not thirty separate failures that all trace back to the same edit with no note that they're related.
• Independent of what your suite currently covers.Because it walks pages rather than running assertions, a scan can flag drift on a page the suite only touches through one narrow test — the same finding a fuller suite would eventually surface, just without needing one.

Keep reading. What happens when a changed element does reach a run is self-healing test automation, and flaky tests separates a moved element from a slow page. How it works puts recording, healing, drift and reports in order.