要素取得が壊れる理由
せっかく書いた自動テストが、ある日突然動かなくなる。
「昨日まで動いていたのに、なぜ？」
これは自動テストを運用する上で、必ず経験する壁です。ここでは、要素取得が「壊れる」主な原因を理解しておきましょう。
壊れる主な原因
1. サービス側のUI変更
最も一般的な原因です。開発チームがUIを改善・変更した結果、テストが動かなくなります。
- ボタンのテキストが「ログイン」→「サインイン」に変わった
- ボタンのデザインが刷新され、クラス名が変わった
- ページのレイアウトが変更され、要素の階層構造が変わった
// 以前は動いていた
page.getByRole('button', { name: 'ログイン' })
// テキストが変わって動かなくなった
// → 'サインイン' に修正が必要
2. フィーチャーフラグによる切り替え
開発現場では「フィーチャーフラグ」という仕組みで、新機能のON/OFFを切り替えることがあります。
- 昨日はOFFだった新UIが、今日からONになった
- 特定のユーザーにだけ新しい画面が表示される
- 段階的に新機能をロールアウトしている
テスト環境と本番環境でフラグの状態が違うと、テストが不安定になります。
3. ABテストによる表示の違い
マーケティングやUX改善のために、ユーザーによって異なる画面を表示する「ABテスト」が行われることがあります。
| パターン | 表示内容 |
|---|---|
| Aパターン | 「今すぐ購入」ボタン（青色） |
| Bパターン | 「カートに追加」ボタン（緑色） |
テストを実行するたびに違うパターンが表示されると、テストが通ったり落ちたりします。
4. 動的に生成されるID・クラス名
モダンなWebフレームワークでは、ビルドのたびにクラス名やIDが自動生成されることがあります。
<!-- 今日のビルド -->
<button class="btn-x7k9m">ログイン</button>
<!-- 明日のビルド -->
<button class="btn-p2n4q">ログイン</button>
このような動的な値に依存したテストは、すぐに壊れてしまいます。
5. 非同期処理・タイミングの問題
ページの読み込みが遅かったり、データの取得に時間がかかったりすると、要素がまだ表示されていない状態でテストが実行されることがあります。
- ネットワークが遅い環境でテストが落ちる
- サーバーの負荷状況によって結果が変わる
- アニメーション中に要素を操作しようとして失敗する
壊れにくいテストを書くために
| 対策 | 説明 |
|---|---|
| 役割ベースのロケーターを使う | getByRole は見た目の変更に強い |
| 動的な値に依存しない | 自動生成されるクラス名やIDは避ける |
| 適切な待機を入れる | Playwrightの自動待機機能を活用する |
| テスト環境を安定させる | フラグやABテストの状態を固定する |
まとめ
要素取得が壊れる原因は様々ですが、ほとんどは「変化」によるものです。
- サービスのUIが変わる
- 設定やフラグが変わる
- 表示内容がユーザーによって変わる
- 生成されるコードが変わる
これらの変化に対応できる「変更に強いテスト」を書くことが、自動テストを長く運用するための鍵となります。