自己修復ロケーター（Self-Healing Locator）

自己修復ロケーターとは、復旧メカニズムを備えた UI テストのロケーターです。たとえば id が変わったことで本来のロケーターが要素を見つけられなかった場合、ツールは元の要素について把握していた情報（タグ、テキスト、属性、位置、隣接要素）に最もよく一致する要素をページから探して使い、通常はその「修復（heal）」を記録して、誰かがテストを更新できるようにします。目的は、無害なマークアップの変更による失敗を減らすことです。

実際の仕組み

ほとんどの実装は同じパターンに従います。

1. 成功した実行時に、テストが触れた各要素のフィンガープリントを保存する。
2. ロケーターが失敗したら、ページ上の候補要素をそのフィンガープリントと照合して採点する。
3. 最も高い候補がしきい値を超えていればそれを使い、置き換えをログに記録する。そうでなければ通常どおり失敗させる。

このような属性の類似度に基づく修復は確立された技術です。商用ツールが提供しているほか、Selenium 向けのオープンソースの選択肢として Healenium があります。LLM ベースの修復、つまりモデルがページやアクセシビリティツリーを読み取って新しいロケーターや修正済みのテストを提案する方式は、より新しいものです。Playwright 1.56 で導入されたテストエージェントには、失敗したテストの修正を提案する healer が含まれています。これらは自動操縦ではなく、レビュー用の変更を提案するアシスタントとして扱ってください。

本当のリスク：本物のバグを「修復」してしまう

修復は、変更が見た目だけのものだったと仮定しています。しかし、そうでないこともあります。

• 「送信」ボタンが誤って削除され、healer が代わりに「下書き保存」をクリックする。
• フィールドのラベルが「メールアドレス」から「ユーザー名」に変わった。これは本来テストが指摘すべき、実際の要件変更です。
• 似た行が 2 つあり、healer が間違った方を選んだため、テストが誤ったデータに対して合格してしまう。

どのケースでも、失敗すべきテストがグリーンになってしまいます。修復を誠実に保つためのルールは次のとおりです。

• すべての修復を報告し、リリースゲートでは実行を失敗させる（少なくともフラグを立てる）。
• 修復をコード変更に変える。 提案されたロケーターはレビューで採用・却下を判断し、ツールが黙って使い続けないようにします。
• 操作だけでなく結果をアサーションする。 そうすれば、間違った要素をクリックしても次のアサーションで失敗します。

まずロケーターを直す

自己修復が対象とする壊れやすさの多くは、長い XPath のチェーン、自動生成されたクラス名、インデックスベースのパスといった脆いセレクターに起因しています。Playwright の getByRole('button', { name: 'Submit' }) のようなユーザー視点のロケーターや、安定した data-testid 属性を使えば、推測に頼ることなく、その必要性の大半はなくなります。