Simple Science

最先端の科学をわかりやすく解説

# コンピューターサイエンス# ソフトウェア工学

ウェブアプリのフレークテスト対策

自動待機生成を通じてUIテストの不安定さを減らす新しいアプローチ。

― 1 分で読む


フレークなUIテストの修正フレークなUIテストの修正るよ。自動待機はテストの信頼性と効率を向上させ
目次

ウェブアプリケーションは、期待通りに動作するか確認するためにテストが必要なんだ。大事な方法のひとつがエンドツーエンドテストで、アプリケーションの全体のワークフローをチェックするって感じ。つまり、実際のユーザーがアプリとどうやってやりとりするかをシミュレーションして、スムーズに動いているかを確認するんだ。でも、多くの人が知っているように、これらのテストは時々不安定な結果を出すことがあるんだ。この不安定さを「フレイキネス」って呼んでる。

フレイキーなテストは大きな問題で、あるときはパスしても、次のときは失敗することがあるんだ。コードに変更がなかったとしてもね。これが開発者たちを混乱させたり、何が問題なのかを理解するのに時間を無駄にしたりする原因になるんだ。フレイキネスの一般的な理由は、テストコードとウェブアプリケーションの実際のコードが実行される順番が予測できないからだ。この問題は特にユーザーインターフェース(UI)をチェックするテストで顕著になる。

UIテストにおけるフレイキネスの問題

UIベースのフレイキネスは大きなチャレンジなんだ。テストはUI要素が次のコマンドに準備できている正確なタイミングを知る必要があるんだ。これが難しいのは、テストを実行するコードがユーザーインターフェースの挙動を必ずしも理解しているわけじゃないから。しばしば、あるコマンドが実行されると、それがUIに変化を引き起こすんだけど、その変化がすぐには現れないことが多い。もしテストコマンドがUIが完全に更新される前に進んじゃったら、テストが予期せず失敗することがあるんだ。

昔は、いくつかの開発者はテストスクリプトに遅延を追加してフレイキネスを修正しようとしたんだ。この遅延は、次のコマンドを実行する前に固定時間待つようにしてた。それによって、必要以上に待つことになって、テストが遅くなることが多かったんだ。

より良い待機の必要性

長い固定遅延の課題を考えると、UIが更新されるのに必要なだけ待つ、より効果的なアプローチが求められるんだ。ここで「明示的待機」のアイデアが登場する。設定された時間を待つんじゃなくて、次のステップに進む前に満たすべき特定の条件をチェックするんだ。これによって、時間を大幅に節約できて、テストがよりスムーズに実行できるんだ。

でも、これらの待機をどこにどのように追加するかを決めるのは、開発者にとってとても難しいんだ。彼らはフレイキネスがどこで起こるかを手動で推測したり、先に進む前にどんな条件が必要かを考えたりしなきゃいけないんだ。これが人間のミスの可能性を生んで、テストを書くプロセスを複雑にしちゃう。

提案された解決策:自動待機生成

この課題に取り組むために、私たちは正しい場所に明示的な待機を自動的に追加する新しい手法を提案するんだ。このアイデアは、コマンドが実行されたときにブラウザのUIの変化を監視して、その情報を使って待機するタイミングを決めるってこと。

仕組み

  1. 変化の記録:最初のステップは、ウェブページの構造を表すドキュメントオブジェクトモデル(DOM)で起こる変化を観察すること。コマンドが実行されると、DOMにさまざまな変化を引き起こすことがあるんだ。この変化をツールを使って追跡することで、リアルタイムで何が起こっているかの情報を集められる。

  2. 待機条件の生成:この情報を得たら、次のコマンドが実行される前に満たすべき特定の条件を作成できる。たとえば、あるコマンドがUI要素を更新する場合、その要素が期待される値になっているかを確認する待機条件をチェックできるんだ。

  3. 待機の実装:最後に、ツールが自動的に生成された待機条件を元のテストコードに挿入する。これにより、開発者はフレイキーなテストが進行を妨げる心配をせずにアプリケーションの構築に集中できるようになるんだ。

効果の評価

私たちの解決策がどれほど効果的かを確認するために、122の異なるフレイキーなテストをさまざまな実プロジェクトでテストした。7つの人気プロジェクトを見て、結果は期待以上だった。私たちの方法は、高い割合でフレイキーなテストを修正し、単純な固定待機と比べて失われた時間を大幅に削減したんだ。

結果

  1. フレイキーコマンド:テストの多くのコマンドがフレイキーであることがわかった。これは、多くのコマンドがテスト中に不安定な結果を引き起こす可能性があるってこと。

  2. 実行オーバーヘッド:私たちの方法と従来の暗黙の待機を比較した。暗黙の待機は全体のテストプロセスを遅くすることが多いけど、私たちの方法は実行オーバーヘッドをかなり低く保った。これは時間が重要な開発環境にとって大事なんだ。

  3. 修正率:私たちの解決策は、ほぼすべてのフレイキーなテストを修正することができた(成功率98%)が、従来の方法は一貫した結果を提供できなかった。

新しいアプローチの利点

私たちの自動待機生成技術の利点には以下がある:

  1. 効率性:テストは本当に必要なときだけ待機が追加されるので、テストが大幅に速くなる。無駄な遅延はもう必要ない。

  2. 高い精度:特定の条件がチェックされることで、テストのフレイキネスが大きく減少する。これによって開発者はテストをもっと信頼できるようになる。

  3. 手作業の削減:待機を挿入するプロセスを自動化することで、開発者は時間を節約でき、人為的なミスを減らすことができる。

課題と制限

この解決策は大きな可能性を示すものの、いくつかの課題もある:

  1. ウェブアプリケーションの複雑さ:一部のウェブアプリケーションは非常に複雑で、その中の相互作用が予期しない挙動を引き起こすことがある。これが変化を正確に追跡し、最適な待機条件を決定するのを難しくするかもしれない。

  2. フレームワークの制限:現在の実装は主にSeleniumやCypressのような人気のテストフレームワークをサポートしている。他のフレームワークをサポートすることは、次の重要なステップだ。

  3. サードパーティライブラリとの統合:フレイキーなテストはUIの変化とは無関係な問題、たとえばサードパーティライブラリの問題から生じることがある。私たちの方法は主にDOMの変化を監視することに焦点を当てていて、これらのライブラリの内部状態の変化には対応できないかもしれない。

今後の作業

今後の改善のために、いくつかの方向性がある:

  1. フレームワークのサポート拡大:ツールを追加のテストフレームワークで動作するように拡大することで、もっと多くの開発者がこの解決策の恩恵を受けられるようになる。

  2. 業界とのコラボレーション:複雑なウェブアプリケーションを管理する大企業と協力することで、現実世界の課題についての深い洞察を得て、ツールをさらに洗練させることができる。

  3. 広範なデータセットの収集:さまざまなプロジェクトからもっとデータを集めることで、異なるタイプのUIの挙動を認識できるように、ツールをさらに効果的にできる。

結論

ウェブアプリケーションにおけるフレイキーなテストは、開発を遅くし、混乱を引き起こす可能性がある。明示的な待機を自動生成することで、ウェブのエンドツーエンドテストをもっと信頼性が高く、効率的にできる。これによって、開発者は時間を節約できるだけじゃなく、テストプロセスに対する信頼も高まる。克服すべき障害はあるけど、スムーズな開発サイクルの可能性は明らかだ。

オリジナルソース

タイトル: WEFix: Intelligent Automatic Generation of Explicit Waits for Efficient Web End-to-End Flaky Tests

概要: Web end-to-end (e2e) testing evaluates the workflow of a web application. It simulates real-world user scenarios to ensure the application flows behave as expected. However, web e2e tests are notorious for being flaky, i.e., the tests can produce inconsistent results despite no changes to the code. One common type of flakiness is caused by nondeterministic execution orders between the test code and the client-side code under test. In particular, UI-based flakiness emerges as a notably prevalent and challenging issue to fix because the test code has limited knowledge about the client-side code execution. In this paper, we propose WEFix, a technique that can automatically generate fix code for UI-based flakiness in web e2e testing. The core of our approach is to leverage browser UI changes to predict the client-side code execution and generate proper wait oracles. We evaluate the effectiveness and efficiency of WEFix against 122 web e2e flaky tests from seven popular real-world projects. Our results show that WEFix dramatically reduces the overhead (from 3.7$\times$ to 1.25$\times$) while achieving a high correctness (98%).

著者: Xinyue Liu, Zihe Song, Weike Fang, Wei Yang, Weihang Wang

最終更新: 2024-02-15 00:00:00

言語: English

ソースURL: https://arxiv.org/abs/2402.09745

ソースPDF: https://arxiv.org/pdf/2402.09745

ライセンス: https://creativecommons.org/licenses/by/4.0/

変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。

オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。

著者たちからもっと読む

類似の記事