A better filter for automated UI testing
Rank flows by how long a breakage would go unnoticed, not by how important they are. An export, an invite, a settings page, a scheduled digest. Each one matters to somebody and none of them has a crowd watching, so a regression sits there for a month.
Second filter: how often does the flow change. A screen that is redesigned every sprint will cost more in maintenance than it returns. Cover it once it settles.
The three costs
Selectors
A redesign that changes nothing functional turns the suite red.
Where most maintenance time actually goes.
Waiting
Fixed delays are slow and still flaky. Correct waits need to know what to wait for.
Most flakiness traces back here.
Authored coverage
You cover what someone wrote, which is the interesting flows rather than the ones that break.
The first two are addressable with discipline. The third is structural: authored coverage is bounded by author time, and author time does not grow.
Three habits that save the most
Anchor on stable attributes. A dedicated test attribute rather than a CSS path. This removes most redesign breakage on its own.
Wait for state, never for time. Wait for the element or the response. A fixed delay is both slow and unreliable.
Assert what a reload would confirm. A success toast is not evidence that anything persisted.
Why suites get deleted
Not because they find nothing. Because the ratio of real failures to maintenance failures gets bad enough that people stop reading the results. Once a red build means "probably a selector" rather than "probably a bug", the suite has stopped working even though it still runs.
Protecting that ratio is the actual job, and it is more about how steps are expressed than about how many tests you have.
Coverage that does not depend on author time
Steps expressed as intentions survive cosmetic change, and coverage generated from the product rather than from someone's memory includes flows nobody would have written. That is the part of the cost that discipline cannot fix.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
The dashboard covers the same ground for anyone who does not want a local install, and the full command surface lives in the CLI repository.
The suite size that stays useful
There is a size beyond which a browser suite starts costing more than it returns, and it is smaller than most teams expect.
The constraint is not runtime, it is attention. A suite of thirty flows produces failures that somebody investigates. A suite of three hundred produces a daily list, and lists get triaged rather than read. Once triage starts, the marginal test is adding noise rather than coverage, no matter how well written it is.
So the useful question when adding a test is not whether the flow matters. It is whether you would investigate this test failing on a Friday afternoon. If the honest answer is that you would rerun it and move on, the test is already noise and writing it makes the suite worse.
Run it on every change
The trigger matters more than the mechanism. Pointing it at your deployment event means every change is checked without anyone deciding to; the GitHub App does that from the dashboard, and a GitHub Actions step does it from inside your workflow.
Where TestSprite changes the arithmetic
The third cost, coverage bounded by author time, is the one discipline cannot fix, and it is what TestSprite removes. Cases are generated from your product and refined in plain language, so the quiet flows get covered without anyone finding an afternoon to write them.
The first two costs improve as a side effect. Steps are stored as intentions rather than as paths through the DOM, so a redesign that moves a button does not turn the suite red, and waiting is handled rather than tuned per test. Those two are where most maintenance time goes.
What that protects is the number that decides whether a suite survives: the share of red builds that are real bugs. Keep that high and people keep reading results, which is the difference between coverage and a job that runs nightly.
How many UI tests should we have?
Fewer than you think, chosen by how quietly a breakage would go unnoticed. A small suite people trust beats a large one people ignore.
What is a reasonable pass rate to accept?
Anything below very high means people stop reading results. Chasing the last few percent of flakiness is worth more than adding new tests.
Should UI tests run on every commit?
On every pull request is the usual right answer. Every commit is often too slow to be useful and gets disabled.
What about visual regression?
A separate concern with a separate tolerance problem. Useful for design systems, noisy for application screens.
Do we still need manual testing?
For exploratory work and anything requiring judgement about whether something feels right, yes. For repeating the same checks, no.
Cover what would fail quietly.
Automated UI testing should be chosen by how long a breakage would go unnoticed rather than by importance. Anchor on stable attributes, wait for state, assert what a reload confirms, and protect the ratio of real failures to maintenance noise.