How does a self-healing locator score candidate substitutes when its original element is gone?
answer
- The vanished element left a description behind
- Compare it with what is on screen now
- Several features, each weighted differently
- Attributes and text outrank position
- A near-tie means no real identification
basics
~20 sA self-healing locator ranks the elements now on screen against a description of the vanished element captured on the last clean run - attributes, visible text, kind of control, neighbouring labels, position - and substitutes the highest-scoring candidate.
solid answer
~50 sOn the last run where the locator resolved to exactly one element, the mechanism records a **description** of it: identifying attributes, visible text, what kind of control it is, and where it sat relative to its neighbours. When the stored locator later matches nothing, every element now on screen is scored against that description feature by feature, and the weighted sum becomes a confidence number. Attributes and text usually carry the most weight because they survive restyling; position carries the least, since a relayout moves everything without changing behaviour. The kind of control is normally a filter rather than a weight, so a label can never repair a button. Ties matter as much as the top score: two candidates within a hair of each other mean the description no longer identifies one element, and substituting either is a guess.
code
pseudocode · 25 lineson step 'submit the order':
matches = find_all(stored_locator)
if count(matches) == 1:
use(matches[0]); return
desc = description_from_last_clean_run(step)
scored = []
for e in elements_on_screen():
if e.control_kind != desc.control_kind:
continue # wrong kind is never a repair
score = 0.40 * attribute_similarity(e, desc)
+ 0.25 * text_similarity(e, desc)
+ 0.20 * neighbour_text_similarity(e, desc)
+ 0.10 * ancestor_path_similarity(e, desc)
+ 0.05 * position_similarity(e, desc, screen_size)
scored.add(score, e)
sort_descending(scored)
best, runner_up = scored[0], scored[1]
record(step, desc, best, runner_up) # always, repaired or not
if best.score >= THRESHOLD and (best.score - runner_up.score) >= MARGIN:
use(best.element)
else:
fail(step, 'no candidate identified the element')go deeper
Be ready to say what a self-healing locator does at all: when the stored locator matches nothing, it looks for the most similar element on screen and continues with that one instead of failing the step immediately.
Explain the mechanics - a description captured on a passing run, per-feature similarity, weights favouring attributes and text over position, and the kind of control used as a filter. Expect to be asked how each individual feature is compared.
Show judgement about when a score deserves trust. Talk about the margin to the runner-up, near-identical repeated rows where no description can discriminate, and insisting the mechanism report the winning score and the features that agreed.
Own the position that scoring weights are policy, not a tool detail: what counts as a match decides how much silent change your suite absorbs before anyone hears about it, so the weights belong in a decision the team can point at and revisit.
A **self-healing locator** does not fail the step the moment its stored locator matches nothing. It searches the elements that are present for the one most likely to be the same control, and continues against that substitute. Everything else about healing — the threshold, the audit record, how much you trust a green run — rests on how *most likely* is computed. ## The description captured before the repair is needed Scoring needs something to score against, and the locator itself is no help: it is exactly the thing that stopped matching. So the mechanism snapshots a **description** of the element on a run where the locator resolved to exactly one match. A typical description carries: - **identifying attributes** — whatever stable-looking name, identifier or label the application attaches to the control; - **visible text**, including the text of anything nested inside it; - the **kind of control** — a button, a text field, a list row — as the platform reports it; - **position**: the chain of ancestors down to the element, its index among its siblings, and often its rendered size and coordinates; - **neighbouring text**, frequently the strongest signal of all, because a field is identified by the label beside it far more reliably than by anything carried on the field itself. A mechanism that first looks at the screen *after* the failure has nothing to compare against. That is why the capture happens on a clean run and is dated to it. ## Scoring one candidate At repair time the mechanism enumerates the elements now present and scores each against the stored description, feature by feature. Each feature yields a similarity between 0 and 1: an exact attribute match is 1, a partial text match scores by token overlap or edit distance, a position match scores by how far the candidate sits from where the original was. Those parts are combined into a single weighted sum, and the weights are the real design decision. | Feature | Weight | Why it earns that weight | |---|---|---| | Identifying attribute | Highest | Changes only when a person edits it deliberately; survives restyling and relayout | | Visible text | High | Tracks what the user sees, but moves with copy edits and translation | | Neighbouring text | Medium | Stable while the surrounding structure is; often the real identity of a field | | Kind of control | A filter, not a term | Cheap to check, and a heading is never the repair for a submit control | | Ancestor path and sibling index | Low | One wrapper added anywhere above shifts every index below it | | Rendered coordinates | Lowest | Move with screen size, text length and density while behaviour is unchanged | Two refinements separate a usable scorer from a naive one. First, **control kind is a gate rather than a weighted term**: candidates of the wrong kind are dropped before scoring, so no amount of text similarity lets a label repair a button. Second, positional features must be **normalised to the current screen size** before they are compared, or every run at a different size looks like a change. ## The margin matters as much as the score A team that watches only the top score misreads the mechanism. Compare two screens: - one obvious candidate at 0.92 with the runner-up at 0.31 — the description still picks out a single element, and the substitution is well founded; - three near-identical rows at 0.88, 0.87 and 0.86 — the top score is barely lower, but the description no longer *discriminates*. Choosing the highest is a coin flip presented as a decision. Repeated structures are where this bites: lists, tables, cards, anything the product renders once per record. A scorer worth using therefore tests **both** the best score against the threshold **and** the gap to the second best against a required margin, and treats the failure of either as no identification at all. ## What the scorer must hand back A repair that leaves no evidence is indistinguishable from a step that never ran. Whatever the outcome, the mechanism should emit the step, the description it failed to match, the winning candidate with its score, the runner-up's score, and which features agreed and which did not. That record is what lets a person decide afterwards whether the substitution really was the same control or a lucky text match, and it is the raw material for every rate and trend the team later watches. ## The shape to hold in your head 1. Resolve the stored locator. Exactly one match means no healing happens at all. 2. Load the description captured on the last clean run for that step. 3. Enumerate candidates on the current screen, dropping any of the wrong control kind. 4. Score each remaining candidate feature by feature and weight the parts into one number. 5. Test the best score against the threshold, and the gap to the runner-up against the margin. 6. Record the decision either way — repaired or failed — together with the scores that produced it.
- Why is the gap between the best and the second-best candidate as important as the best score itself?The top score says how well one element fits the stored description; the gap says whether that description still picks out one element at all. Three near-identical rows scoring 0.88, 0.87 and 0.86 mean the description has stopped discriminating, so the winner is effectively arbitrary even though the number looks high. Treat a narrow margin as a failed identification and fail the step.
- Why does the mechanism capture its description on a passing run rather than at the moment of failure?At failure time the original element is already gone, so there is nothing left to describe - only the locator that just stopped matching, which is exactly the thing that failed. Capturing attributes, text, control kind and surroundings on the last clean run gives the scorer a description of the element that demonstrably worked, dated to a known-good state of the application.
saying these in an interview costs you the question
- Thinks repair means retrying the original locator until it matches
- Scores candidates only on their position in the element tree
- Takes the top-scoring candidate as a match without checking the runner-up
- Uses repair as the cure for an element that is merely slow to appear
- Weights a fuzzy text match the same as an exact attribute match
- Cannot say afterwards what evidence a substitution was based on