When a suite repairs its own broken locators and still passes, which product defects does that green run hide?
answer
- A pass can now mean two different things
- The repair replaced something, not nothing
- Moved, relabelled, duplicated, substituted
- Every repair is an unreviewed product change
basics
~20 sA repair hides every change that broke the original anchor: a control that moved, was relabelled, lost its announced name, or was replaced by a different one. The suite reports the flow works while the interface changed.
solid answer
~40 sA self-repairing suite turns a *lookup failure* into a *silent substitution*: when the recorded anchor no longer matches, it scores nearby candidates and drives the closest one instead. That converts a whole class of user-visible change into a pass. The control may have moved behind a menu, been relabelled, lost the name the platform announces, been duplicated so the repair picked the wrong instance, or been swapped for a different control with similar text. None of those is a test problem - each is a product change somebody would want to hear about. The green result is now evidence of very little: that *something* on the page could still be driven. Treat every repair as an unreviewed product diff, not as maintenance the framework did for you.
code
pseudocode · 13 linesresolve(step):
matches = elements matching step.anchor
if matches.count == 1:
return matches[0], repaired = false
# nothing matched what the case recorded
candidates = rank_visible_elements(against = step.remembered_traits)
best = candidates.first()
if best.score >= accept_at:
note_substitution(step.anchor, best) # often only to a log
return best.element, repaired = true
fail("no element matched the recorded anchor")go deeper
Be ready to say what a repair replaces: the recorded anchor stopped matching, so the runner drove a different element instead. Name two changes that hides, such as a control that moved and one that was relabelled.
Explain the mechanism that creates the mask - a lookup failure becomes a substitution, recorded where nobody reads it - and list the defect classes that vanish because of it.
Show that you would treat each substitution as an unreviewed product diff, and describe how you would get it in front of a reviewer before the run is trusted. Interviewers want the operating habit, not the definition.
Own the tradeoff: adaptive lookup buys suite survivability and spends the suite's ability to report interface change. Say which suites you would let adapt, and what evidence would make you switch it off.
## What a self-repairing lookup actually does An automated case reaches a control through an **anchor**: whatever the runner uses to identify the element - the text a user reads on it, the name the platform announces for it, an attribute added so that tests can find it, or a structural path through the page's element tree. In an ordinary suite that anchor is a hard contract. If it stops matching, the lookup raises an error, the case fails, and somebody is obliged to look. A self-repairing suite breaks that contract deliberately. When the recorded anchor matches nothing, it inspects the elements that *are* present, compares each against the traits it remembers about the original, picks the closest, and drives that one instead. The case continues, and it usually goes green. The reason teams do this is real. Most anchor breakages are noise: a wrapper appeared, a generated class name rotated, a container was renamed. Failing two hundred cases over a change no user can perceive costs a morning and teaches nobody anything. Adaptive lookup buys survivability. The bill arrives as a question the mechanism cannot answer. From inside the runner, *somebody restructured the markup* and *the product changed in a way a user would file a bug about* look identical: the recorded anchor stopped matching, and something similar is nearby. The mechanism resolves that ambiguity by proceeding - and every time it proceeds, whatever caused the break is absorbed. ## The defect class that disappears Each of the following is a change a user could notice, and each is a change that a successful repair reports as a pass: - **The control moved.** The primary action left the form footer and now lives behind a collapsed menu. The runner found it anyway; a user has to hunt for it. - **The control was relabelled.** *Submit order* became *Continue*, which changes what the user is told they are agreeing to. The repair matched on shape and neighbourhood and never read the words. - **The control lost the name the platform announces.** An icon replaced a labelled button. Some users can no longer address it at all, and the substitution routed around exactly that loss. - **The wrong instance was chosen.** A list grew a second control with the same text, and the repair took the one nearest the remembered position - sometimes the intended row, sometimes not. - **A different control was substituted.** *Save draft* now sits where *Publish* used to, scores well on similarity, and gets driven. The assertions that follow are about the wrong action. - **The control changed kind.** A link became a menu entry, or an enabled button became a placeholder the runner still activated. | What actually changed | Plain suite reports | Self-repairing suite reports | | --- | --- | --- | | A wrapper element was added around the control | fail | pass | | The action moved behind a collapsed menu | fail | pass | | The label now says something different | fail | pass | | The control no longer announces a name | fail | pass | | A second identical control appeared in the list | fail | pass | That table is the whole problem: the left column mixes one change nobody cares about with four a team would want to hear about immediately, and the right column collapses all five into one word. ## Why "it passed" stops being evidence A pass in a plain suite carries a specific claim: *the control identified this way was found, and behaved as asserted.* A pass after a repair carries a much weaker one: *some element the runner judged similar was found, and behaved as asserted.* The assertions are still real, but they ran against whatever was substituted. They confirm that a flow could be completed by the runner. They say nothing about whether the path a person takes to that flow still exists. That weakening is worse than an outright failure, because a failure puts the change in front of a person: it produces a red build, a triage queue and an owner. A repaired pass removes the change from the record entirely, and the defect ships with a green run attached to it - the strongest available argument against anyone looking. ## Working with it rather than against it 1. **Treat every repair as an unreviewed product diff.** The recorded anchor and the element that replaced it are a change description. Somebody accepts it as an intended rename, or files it as a defect. Nothing else is a resolution. 2. **Make a repair change what the run looks like.** A substitution that reaches only a file under the artefacts directory was not reported. 3. **Keep a set of steps that are never repaired** - the ones where substituting a different element changes what the case means rather than just how it finds things. 4. **Watch the volume, not only the single case.** A suite whose substitution count climbs release over release is telling you the interface has drifted away from what the cases describe, whatever colour the run came out. None of that requires giving up adaptive lookup. It requires refusing to let the mechanism's convenience quietly become the team's definition of *the product is fine*.
- If the repaired case passes, what evidence do you actually have that the product still behaves correctly?Only that some element the runner judged similar could be driven, and that the assertions after it held. That is weaker than it sounds: those assertions ran against whatever was substituted, so they show the flow completed, not that a user's path to it survived. The evidence you need is the difference between the recorded anchor and the substitute, read by a person.
- Why is a repaired pass worse for a team than an outright failure?A failure puts the change in front of somebody: it produces a red build, a triage queue and an owner. A repaired pass removes the change from the record entirely - no colour, no queue, no owner. The defect then ships with a green run attached to it, which is the strongest available argument against anyone looking at it.
It is a spellchecker that silently rewrites any word it does not recognise. The page reads clean, and you never learn which words it changed.
saying these in an interview costs you the question
- Says a green run proves the interface is unchanged
- Treats every repair as free maintenance the framework performed
- Assumes repairs only ever absorb cosmetic markup churn
- Believes a high similarity score means the right element was driven
- Thinks the only cost of repair is a slower run