Selectorless testing: no selectors to break
Selectorless testing is UI test automation in which a test stores a plain-language goal and an expected outcome, and no element selectors at all. No CSS, no XPath, no stored locator of any kind. The agent that runs the test finds each element on the live page at run time, so when the markup changes there is no saved string for the change to invalidate.
Our stake comes first, because this page intends to define the term. We build TestAutomate, and we built its runner without a selector field in its test schema, so we sit squarely on one side of this argument. The phrase itself still gets used loosely, and the people feeling the pain usually search for the symptom instead. They ask why selectors break tests, or they look for test automation without selectors. This page holds the definition we're prepared to be held to, the mechanism behind it, and the cases where selectors remain the right tool.
What actually breaks when a selector breaks?
The address, not the feature. A CSS selector or an XPath expression names a location in a document's structure, which is what makes it precise and what makes it perishable. Markup and behavior change on different schedules. Developers rename classes, wrap elements in new containers, and flatten component trees for reasons that have nothing to do with the flows a test protects, and any of those edits can orphan a stored locator while every user-facing feature keeps working. The feature survives the redesign. The address doesn't. That mismatch is the recurring maintenance bill of selector-based suites, and it recurs because the coupling recurs, not because anyone wrote the tests badly. We've kept this to one paragraph because the full argument, worked examples and mitigations weighed, already lives in why selectors break tests and what a test stores instead.
What does a test hold instead of selectors?
A goal and an outcome, written the way you'd brief a person. In TestAutomate the artifact is three required fields, an id, a plain-language prompt, and an expected outcome, with optional setup and cleanup prompts around them. Everything else a test can carry, timeouts, tags, test data, is optional. Natural language test automation usually gets pitched as a convenience, prose being easier to write than code, but the consequence that matters is subtraction. When every field is prose, a locator has no field to occupy, and what a test doesn't contain can't go stale.
Element finding happens at run time instead. The agent asks the page for its interactive elements and acts on the element references that come back, and it can locate a control by describing it the way you would, the save button, the row for the newest invoice. There are no user-authored selectors anywhere for a redesign to break, and nothing the agent finds in one run is stored for the next.
That run-time adaptation is also why selectorless testing is best understood as a property of agentic execution rather than a rival category. An agent chooses its own route through the interface while a separate model grades the finished run against the outcome you declared, which keeps the standard fixed even when the route varies. The whole loop, verdicts and guardrails included, is mapped in our pillar on what agentic testing is and how a run works.
What's the difference between self-healing and selectorless testing?
Self-healing patches the locator. Selectorless never stored one. A self-healing layer keeps a selector-based script alive by repairing locators that stop matching, which is real value if you own a large scripted suite, and also a renewed commitment to the selector as an artifact worth preserving. Selectorless testing declines the artifact rather than maintaining it, and that choice changes your week more than it changes your test. Healing hands you repairs to review. Going selectorless hands you judgments instead, the verdicts and flagged assumptions an agent's runs produce. Which of those queues you'd rather staff is the honest core of the debate, and self-healing vs selectorless, from the engineer who did the locator repairs argues it from the side that used to do the repairing.
When are scripted selectors still the right call?
More often than a category-defining page likes to admit. If your interface is stable, your suite is quiet, and locator edits barely register in your repo history, selectors are doing their job fast, cheaply, and deterministically, and an agent-run check costs model calls and minutes where a scripted assertion costs milliseconds. Below the UI, at the unit and API layers, selectors were never the problem, so no-selector testing has nothing to offer there. And removing selectors deletes one class of failure, not failure itself. A test can still go red because the page offered two plausible save buttons, or because the expected outcome asked for less than the feature owes, and it should.
The clean way to decide is to compare what each approach hands you to review each week, because that queue, not the demo, is what your team actually lives with.
| Approach | What lands in your weekly review | What clearing it takes |
|---|---|---|
| Scripted, selector-based | Locators broken by markup changes | A human edits selector strings and re-runs the suite |
| Record and replay | Recordings that drifted from the app | Re-record the flow end to end |
| Self-healing layers | Repairs the tool applied on its own | Confirm each repair grabbed the element the test meant |
| Selectorless, agentic | Verdicts and flagged assumptions | Confirm the change behind each flag was intended |
That last row costs attention too, and we'd rather you price it in now than discover it in week three. Confirming a flag is still work, it just trades editing locator strings for making product judgments. The rows aren't exclusive either. Plenty of teams will keep a scripted layer where the UI is calm and put selectorless testing where the churn is, which is less a compromise than an admission of what each tool is for.
How does TestAutomate do test automation without selectors?
By never asking you for one. Every test you write in TestAutomate is an intent-based prompt with an expected outcome, run by an agent in a real browser, and every test it drafts for you from your product's docs comes out the same way, plain natural language with no code and no selectors in it. When a run fails, the failure can become a pending bug candidate that carries the verifier's reasoning, and filing it in Jira is a human click in the dashboard, never something the tool does on its own.
That verdict view is the payoff of keeping the outcome fixed while the route adapts. When something breaks, the dashboard gives you the reasoning in sentences, not a locator diff.
The billing follows the same no-surprises rule. There's no markup and no per-seat fee. Claude calls bill your own Anthropic account, retrieval is local and free, and only optional voice input uses a separate OpenAI key.
Frequently asked questions
What is selectorless testing?
Selectorless testing is UI test automation in which a test stores only a plain-language goal and an expected outcome, never a CSS or XPath selector. The agent running the test locates each element on the live page at run time, so there is no stored locator string for a markup change to break.
Why do selectors break automated tests?
A selector names a position in the page's markup, not a behavior of the product. When developers restructure that markup during a redesign or refactor, the stored string stops matching, and the test fails even though the feature it protects still works for every user. The break signals a markup change, not a defect.
How does a selectorless test find elements without selectors?
The agent asks the live page for its interactive elements and acts on the element references it gets back. It can locate a control by describing it in plain language, such as the save button, and receives a clickable reference. No element reference is stored between runs, so nothing goes stale.
What does a selectorless test look like?
In TestAutomate, a test is three required fields written in natural language, an id, a prompt stating the intent, and an expected outcome listing what must be true afterward, plus optional setup and cleanup prompts. There is no selector field anywhere in the schema for a locator to occupy.
Do I need test-id attributes for selectorless testing?
No. Test-id attributes exist to give selectors something stable to grip, and a selectorless suite has no selectors to stabilize. The agent finds elements on the live page as rendered, so it works on markup you don't control and on apps that never adopted a test-id convention.
Is selectorless testing the same as natural language test automation?
They overlap but aren't identical. Natural language test automation describes the authoring format, tests written in everyday words instead of code. Selectorless describes what the artifact omits, stored element locators. A tool can accept natural language yet compile it into selectors underneath, and that compiled artifact goes stale like any other.
When are scripted selectors still the right choice?
When the interface is stable and the suite is quiet. If locator repairs are rare in your repo history, selectors are cheap, fast, and deterministic, and an agent-run check spends model calls to solve a problem you don't have. Selectorless earns its cost where the UI changes faster than the tests protecting it.
Hold us to the definition
A term is only worth coining if the coiner can be pinned down by it. Selectorless testing, as we'll be held to it, means the artifact stores a goal and an expected outcome and nothing a redesign can orphan. TestAutomate is pre-launch for teams who want intent-based regression tests and a review queue made of judgments rather than locator repairs.