HEAL_FAILED: nothing scored above 0.6 and testId probed at 0.00
Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
text
Could not locate "signed-in username" (getByTestId('sidenav-username')) and no healing candidate scored ≥ 0.6.
Probed: role=0.42, testid=0.00, label=0.00. Add role/name/testId/label to the heal context or fix the locator.
What I cannot work out is testid=0.00. It is the same test id the primary uses, so of course it found nothing — but then why probe it at all? And where does 0.42 come from?
testid=0.00 is a count of zero. A candidate that matches nothing scores zero outright, before any multiplier is applied. And you are right that declaring the same test id the primary already uses buys you nothing — it is probed because the healer does not assume the primary and the context overlap, but in your case it can only ever confirm what has already failed. Take it out of the context and put something useful there.
0.42 is the role candidate scoring badly rather than not matching. Base 1.0 for role and name, then multiplied down by uniqueness, visibility and enabled. Something with that role is on the page and the healer is not confident it is yours. The event records count, visible and enabled per candidate, so open it and see which multiplier did the damage rather than reasoning backwards from the number.
label=0.00 is the other half of the story: getByLabel('Signed in as') matches nothing, so what you declared as a label is not a label in the accessibility sense. It is almost certainly adjacent text.
The context to write is the one that describes the element instead of restating the primary:
ts
readonly username = this.heal.locator(this.page.getByTestId('sidenav-username'), {
role: 'status', name: /Signed in as/, text: 'Signed in as', description: 'signed-in username',
});
Note the explicit text. Text candidates come from text, or from name when name is a string — a regular expression name gives you no text candidate at all.
The likely root cause, going by the description: a sidenav username is usually rendered twice, once in the sidenav and once in a collapsed mobile menu, or wrapped in a container that is hidden at your viewport. Two matches costs you the uniqueness factor, and one of them being invisible costs you the rest.
Check what your viewport is actually rendering before you rewrite the context.
Separate from the diagnosis: role: 'status' is a rough choice for a name display. If the element is not a live region, that probe is scoring against whatever else on the page claims the role.
We got much better results declaring the container's role and the text, and leaving the test id as the primary.