【ITニュース解説】How would you robustly assert the presence and content of a transient UI element that appears and disappears rapidly in

ウェブアプリケーションのテストは、システムが意図した通りに動くかを確認するために非常に重要だ。特に、現代のウェブサイトやアプリケーションは、ユーザーインターフェース（UI）が非常に動的で、画面上の要素が目まぐるしく変化する場面が多い。例えば、株価のリアルタイム更新、チャットアプリの新しいメッセージ表示、ライブダッシュボードの数値変動など、情報が絶えず更新されるような場面では、画面に一瞬だけ現れては消える、あるいは内容がすぐに変わってしまうUI要素が頻繁に存在する。

システムエンジニアを目指す皆さんにとって、このような動的なUI要素を正確にテストする方法は、品質の高いソフトウェアを開発するために不可欠な知識となる。Playwrightのような自動テストツールを使えば、ユーザーの操作をシミュレートし、ウェブアプリケーションの動作を検証できる。しかし、前述のような「一時的に表示されるUI要素」（これを「トランジェントUI要素」と呼ぶ）のテストは、従来のやり方では一筋縄ではいかない。

何が問題かというと、PlaywrightのtoBeVisible()（要素が見えることを検証）やtoHaveText()（要素が特定のテキストを持つことを検証）といった一般的な検証方法は、要素が常に画面に存在し、内容が安定していることを前提としている場合が多い。しかし、リアルタイムなアプリケーションでは、テストツールが要素の存在を確認しようとした瞬間に、その要素が既に画面から消えていたり、内容が変わってしまっていたりすることが頻繁に起こる。これは「タイミングの問題」（競合状態、またはレースコンディションと呼ばれる）によって引き起こされ、テストが成功することもあれば、同じコードでも失敗することもある、いわゆる「不安定なテスト」（flaky test）の原因となる。開発者はこのような不安定なテストに悩まされ、信頼性のあるテスト結果を得ることが難しくなる。

この問題に対して、Playwrightは非常に堅牢な解決策を提供している。その鍵となるのが、expect.toPass()という機能と、locator.all()というメソッドの組み合わせである。

expect.toPass()は、指定した検証ブロックが成功するまで、一定の時間内（タイムアウト）で自動的に検証を再試行し続ける機能だ。これは、「要素がいつ現れるか分からないけれど、最大でこの時間まで待ってみよう」というシナリオに最適である。例えば、「10秒以内なら何度でも試行して、もしその間に要素が見つかって、かつ指定した内容を持っていたら成功とみなす」といった柔軟な検証が可能になる。

そして、locator.all()は、特定の条件（セレクタと呼ばれる、ウェブページの要素を特定するための目印）に合致するすべての要素を、その時点での最新のウェブページの状態から取得するメソッドである。重要なのは、expect.toPass()ブロック内でこのlocator.all()を使用すると、リトライされるたびにウェブページの構造（DOM）が新たに評価され、その時点での最新の要素リストが取得される点だ。これにより、テストツールが古い情報を基に要素を探しに行ってしまう「古い要素参照エラー」（stale element errors）を防ぎ、常に画面の最新の状態を確認できる。

具体的なテスト戦略は次のようになる。まず、一時的に表示される要素が含まれる、比較的安定した「親の要素」（コンテナ）を特定する。例えば、リアルタイム情報を表示するフィード全体を囲む部分などがこれにあたる。次に、expect.toPass()のブロック内で、この親要素の中にある可能性のあるすべてのアイテムをlocator.all()を使って取得する。この時、まだ目的の要素が表示されていなくても問題ない。なぜなら、expect.toPass()が自動的にリトライしてくれるからだ。

取得したすべてのアイテムの中から、JavaScriptのfind()メソッドなどを利用して、目的の「一時的なUI要素」を探し出す。例えば、「緊急更新：新しいデータを受信しました」といった特定のテキストが含まれるかどうかで判断できる。そして、その要素が見つかったら、expect(targetItem).toBeDefined()で「要素が確かに見つかったこと」を検証し、さらにawait expect(targetItem!).toBeVisible()で「その要素が実際に画面に表示されていること」を検証する。この一連の処理がexpect.toPass()のタイムアウト時間内に成功すれば、テストはパスとなる。もしタイムアウト時間内に見つからなければ、テストは失敗する。

コード例では、page.goto('YOUR_DYNAMIC_APP_URL')でテスト対象のアプリケーションにアクセスした後、expect(async () => { ... }).toPass({ timeout: 10000, intervals: [500, 1000, 2000] });という形で、検証ロジック全体をtoPassで囲んでいる。timeout: 10000は最大10秒間リトライすることを意味し、intervalsはリトライの間隔をカスタマイズできるオプションだ。この柔軟なリトライ機構が、変化の激しいUI要素を確実に捉えることを可能にする。

この手法の大きなメリットは、テストの「安定性」と「堅牢性」を飛躍的に向上させる点にある。不安定なテストは開発者の時間を無駄にし、システムの信頼性を低下させるが、この方法を使えば、一時的なUI要素の出現や変化に動的に対応し、信頼性の高い自動テストを構築できる。

なぜawait page.waitForSelector()のような他の待機方法では不十分なのかという疑問も出てくるかもしれない。waitForSelector()は、特定の要素が画面に現れるまで待つ機能としては有効だが、それは「要素の存在」を待つことに特化している。一時的に現れる要素の場合、ただ現れるのを待つだけでなく、「現れた瞬間に特定の内容を持っているか」を検証し、もし内容が期待と異なれば再度試行する、といった複雑なロジックはwaitForSelector()だけでは実現しにくい。expect.toPass()は、検証ロジック自体をリトライする機能を提供するため、要素の存在だけでなく、内容や可視性といったより詳細な条件を、動的に変化する要素に対して繰り返し適用できる点で優れている。

システムエンジニアとして、このような高度なテストテクニックを理解し、適切に使いこなすことは、変化の速い現代のウェブ開発において非常に重要なスキルとなる。Playwrightのexpect.toPass()とlocator.all()の組み合わせは、リアルタイム性の高いアプリケーションにおけるUIテストの課題を克服し、より信頼性の高い自動テスト環境を構築するための強力なツールとなるだろう。