2026/01/12
やはり俺のPlaywrightはまちがっている。
公式ドキュメントを読み直して気づいた「動く」と「正しく動く」の決定的な違い。
「動けばいい」が生む技術的負債
過去のコードを流用することで、知らず知らずのうちに不安定なテストを生み出していませんか？
過去コードの流用
思考停止のコピー
動いているコードをそのまま使い回し、新たな理解を放棄する。
不安定なテスト
タイミング依存のエラー
要素の準備が整う前に操作を行い、テストがランダムに落ちる。
非推奨APIの使用
競合状態のリスク
waitForNavigation等は競合状態を引き起こす可能性がある。
Locatorという「設計思想」
Locatorは単なる要素特定ではありません。要素が操作可能になるまで「待つ」仕組みが内包されており、テストの安定性を劇的に向上させます。
Evaluate
要素を直接操作。準備不足だと即エラー。
Locator
操作可能になるまで自動で待機して実行。
Actionability Checks
可視性、安定性、操作可能性を自動検証し、タイミング問題を解決。
自動で行われるチェック
Locatorを使用すると、以下のチェックがすべてパスするまで操作が自動的に待機されます。
存在と可視性の確認
要素がDOMに存在し、ユーザーに見えているか。
Attached
Visible
In Viewport
操作可能性の確認
インタラクションを受け取れる状態か。
Stable
Enabled
Receives Events
推奨されるセレクタ優先順位
ユーザーの視点に近いセレクタほど、実装変更に強く堅牢なテストになります。
Role(役割)
アクセシビリティツリーに基づく指定。最も堅牢で推奨される。
Label(ラベル)
フォーム要素のラベルテキストを使用。ユーザーの視点と一致する。
Text(テキスト)
表示されているテキスト内容で指定。直感的だが変更に弱い場合も。
Test ID
テスト専用の属性を使用。どうしても他に適した方法がない場合に。
今こそドキュメントを読もう
「動く」と「正しく動く」の差はドキュメントにあります。急がば回れ、一度立ち止まって読み直してみましょう。
最初のアクション
Best Practicesを読む
公式ドキュメントのBest Practicesページに目を通す。
Locatorへ置き換える
evaluateやwaitForを使用している箇所をLocatorに修正する。
ポイント: ライブラリの作者が込めた設計思想を理解することで、コードの品質は確実に向上します。
今こそ、公式ドキュメントを読み直す時です。
sui Tech Blog