heal:
enabled: true
primaryTimeoutMs: 3000
probeTimeoutMs: 1500
minScore: 0.6
actions: [click, fill, select, assert, hover, check]I understand what the number does. I do not understand what I would gain or lose by moving it. Has anyone actually tuned this, and in which direction?
The number is chosen against the base scores rather than picked out of the air. role and name 1.0, test id 0.95, label 0.9, placeholder 0.8, exact text 0.7, partial text 0.5, css 0.4, and the score is base × uniqueness × visibility × enabled + history with the history bonus capped at 0.1.
So at 0.6 you are saying: a unique, visible, enabled match on anything down to exact text may win; CSS never can, because 0.4 with every multiplier at 1 and a full history bonus is 0.5; and a match that is not unique loses its uniqueness factor and usually falls below the line as well.
Raising it to 0.9 leaves you with test id and role, which is defensible if your application has good test ids. Lowering it below 0.5 turns CSS fallbacks on, and I would not.
One thing that surprises people: setting it to 1 does not disable healing. A unique, visible, enabled role-and-name candidate scores exactly 1.0 and the comparison is greater-than-or-equal. Use heal: { enabled: false } if off is what you want.
We raised it to 0.8 on one project and the effect was not "fewer wrong heals", it was "more HEAL_FAILED on the same locators that used to heal via text". Which we wanted, because the failures pointed straight at page objects with thin contexts.
Six weeks later the contexts were better and we could have put it back, but there was no longer any reason to. Tune it as a forcing function on your own contexts rather than as a correctness dial.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question