A UI automation test you can write as a boolean expression

The SERP gap: selectors are not flat strings

Read the top results for "ui automation test" and you will see the same essay repeated: what UI automation is, why it matters, a list of tools. What none of them show is the thing that actually breaks tests in production. A real button on a real screen has more than one attribute you care about. It has a role, a name, a visibility flag, maybe a process scope, maybe a locale-specific label. The moment you try to match more than one of those with a single runner, you fall off the happy path and start chaining imperative locators or writing JavaScript predicates. That is where flake enters.

Terminator took the opposite route. Selectors are an expression grammar. You can write role:Button && (name:OK || name:Confirm) && !visible:false directly in the locator string and the engine will parse it, flatten it, and evaluate it as a single predicate. The rest of this page shows exactly how.

The anchor fact

Everything on this page traces back to one file: crates/terminator/src/selector.rs. It is 753 lines long. The first interesting bit is the Selector enum at line 5: about twenty variants, from Role and Name through the spatial family (RightOf, LeftOf, Above, Below, Near) to three boolean nodes (And(Vec), Or(Vec), Not(Box)). The fact that And and Or hold a vector, not a pair, is the whole trick.

How the parser turns your string into a predicate

The pipeline has four stages. Each one maps to a specific function in selector.rs. Read them in order and you have the whole engine.

Why flattening matters

A naive boolean parser builds a binary tree: every AND has a left and a right, and long expressions become deeply nested. Terminator does not. When apply_operator sees an AND whose left operand is already Selector::And(vec), it appends the new right operand into that vec. The resulting tree stays shallow. Evaluation against an element is a single loop over the vector, not a recursion through a binary tree.

// Selector::And nested as a binary tree
And(
  Box(a),
  Box(And(
    Box(b),
    Box(And(
      Box(c),
      Box(d)
    ))
  ))
)
// evaluate(elem) recurses 4 levels deep

Where each piece lives

If you want to read the code yourself, here is the route from raw string to matched element. Every label below is a real identifier you can grep for.

Real expressions you can drop into a test

None of these require wrapper functions, chained calls, or JS predicates. They all live inside a single locator string.

Using it from the SDK

The TypeScript binding takes the full expression verbatim. No tagged template literal, no imperative chaining required. The Rust parser sees the same bytes you wrote.

Watch the parser run

Here is what a real selector looks like when you enable verbose parser output. The expression is parsed once and cached by the locator.

What this buys your UI automation test

Versus what everyone else ships

Most guides compare frameworks by feature checkboxes. The relevant axis for a UI automation test is how the locator composes.

A mental model in four steps

Twelve atomic selectors you can combine

Each of these can appear anywhere in a boolean expression.

Recap: what makes this uncopyable

Competing runners tokenize selectors into one atom and lean on the host language for composition. Terminator ships the expression grammar inside the selector string itself. There is a 0-line file with a 0-precedence Shunting Yard parser and an AND/OR flattener that keeps evaluation linear. You can read every line. You can grep for every identifier on this page. The file path, the precedences, and the flattening behavior are the concrete things that are checkable and that no competitor page names.

Frequently asked questions