【ITニュース解説】Mastering Cypress Retries: How to Efficiently Re-Run Only Failed Tests with Mochawesome & Dynamic…

Webアプリケーション開発において、システムがユーザーにとって期待通りに動作するかどうかを自動で確認するテストの一つに、End-to-End（E2E）テストがある。これは、実際のユーザーのようにブラウザを操作し、アプリケーションの一連の動作全体を検証するものであり、ソフトウェアの品質を保証するために非常に重要である。しかし、このE2Eテストには「不安定なテスト」（flaky test）という課題が頻繁に発生する。不安定なテストとは、コードに問題がないにもかかわらず、ネットワークの遅延や一時的な環境要因、あるいは非同期処理のタイミングのずれなど、不確定な要素によって、ある時は成功し、またある時は失敗するといった挙動を示すテストのことを指す。

このような不安定なテストがいくつか発生するたびに、テストスイート全体を最初から再実行することは、特に大規模なプロジェクトや、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインのような自動化された開発フローにおいて、膨大な時間とリソースの無駄につながる。開発者は、失敗した特定のテストだけを効率的に再実行できるような仕組みを求めている。本稿では、Cypressという人気のあるE2Eテストツールを使い、失敗したテストだけを検出し、それらを効率的に再実行するための自動化されたソリューションについて解説する。このソリューションは、Mochawesomeレポート、Node.jsスクリプト、そして@cypress/grepというプラグインを組み合わせて実現される。

まず、テスト結果の詳細な情報を得るために、Mochawesomeというレポートツールを導入する。Mochawesomeは、Cypressの内部で使われているテストフレームワークであるMochaと連携し、テストの実行結果を美しくインタラクティブなHTMLレポートとして出力できる。このレポートには、各テストの成功・失敗のステータスだけでなく、テストの完全なタイトルや、そのテストが実行されたスペックファイル（テストファイル）のパスといった、詳細な情報が含まれるため、どのテストが失敗したのかを正確に特定するために不可欠である。MochawesomeをCypressに設定するには、まず必要なパッケージをインストールし、次にcypress.config.tsファイルにMochawesomeを使用する設定と、複数のテストファイルから生成された個別のJSONレポートを一つに結合し、最終的なHTMLレポートとJSONレポートを生成するためのフックを追加する。これにより、Cypressの実行後には、個々のテスト実行結果のJSONファイル群と、それらを統合した最終的なHTMLおよびJSONレポートが指定されたディレクトリに生成されるようになる。

次に、このMochawesomeによって生成された統合JSONレポートを解析し、失敗したテストのデータを抽出するNode.jsスクリプトを作成する。このスクリプトは、cypress/reports/mochawesome/combined-report.jsonというファイルからレポートデータを読み込み、その内容を順番に調べて、失敗とマークされたテストを特定する。失敗したテストが見つかると、そのテストの完全なタイトル（親となるテストブロックの記述も含む）と、テストが記述されているスペックファイルの相対パスを収集する。収集されたテストのタイトルとスペックファイルパスは、重複を排除し、最終的にcypress/temp/failed-tests.jsonというファイルに保存される。このファイルは、後続のステップで失敗したテストのみを再実行するために使用される、重要な「失敗テストのリスト」となる。

そして、この抽出された失敗テストの情報を使って、Cypressを動的に設定し、特定のテストだけを再実行する。この際、コマンドラインの引数として大量のテストタイトルを渡すと、オペレーティングシステムによる引数の長さ制限（ENAMETOOLONGエラー）に引っかかる可能性があるため、別の方法でCypressの設定を動的に変更する。この目的のために、@cypress/grepというプラグインを利用する。@cypress/grepは、テストタイトルに含まれるキーワードに基づいてテストをフィルタリングする強力な機能を提供する。 具体的には、run-failed-tests.jsというNode.jsスクリプトが、先ほど作成したfailed-tests.jsonを読み込む。スクリプトは、そこに含まれる失敗したテストのタイトルを結合し、Cypressの環境変数であるconfig.env.grepにその値を注入する。さらに、失敗したテストが存在するスペックファイルのみを実行対象とするため、config.env.CYPRESS_GREP_SPEC_PATTERNにスペックファイルのパスリストを注入する。これらの設定値は、Cypressの起動前に一時的にcypress.config.tsファイルに直接書き込まれる。これにより、Cypressは起動時にこれらの動的な設定を読み込み、指定された失敗テストとスペックファイルのみを対象として実行する。Cypressの実行が完了した後、run-failed-tests.jsスクリプトは、元のcypress.config.tsファイルの内容を正確に復元し、ファイルがクリーンな状態に戻ることを保証する。これは、CI/CD環境での安定性を保つ上で非常に重要なステップである。

テストの信頼性を確保するためには、テスト環境のクリーニングも重要である。Cypress自体も実行ファイルをキャッシュしているため、npx cypress cache clearコマンドで定期的にキャッシュをクリアすることが推奨される。また、テスト対象のアプリケーションのデータも、各テスト実行前に一貫した状態にリセットすることが理想的である。これには、データベースのシード（初期データ投入）や、テストによって作成されたデータの削除、あるいはUIの状態を初期化するAPI呼び出しなどが含まれる。これらのクリーニング手順をテストワークフローに組み込むことで、テストの再現性と信頼性が向上する。

最後に、これらのステップを統合し、開発者が簡単に利用できるワークフローを構築する。これはpackage.jsonのscriptsセクションに一連のコマンドを定義することで実現する。例えば、npm run test:fullというコマンドで全てのCypressテストを実行し、その後にnpm run test:failedというコマンドで失敗したテストのみを再実行できるような流れを作る。test:failedコマンドは、まず既存のレポートと一時ファイルをクリーンアップし、次に全てのCypressテストを実行し、そのMochawesomeレポートから失敗テストを抽出し、最後に抽出された失敗テストのみを再実行するスクリプトを実行する。

この自動化されたアプローチを採用することで、開発チームはテスト失敗時に費やす時間を大幅に削減し、より迅速にフィードバックを得られるようになる。不安定なテストに悩まされることが減り、CI/CDパイプラインの効率が向上し、開発プロセス全体がよりスムーズで生産的になるのである。この高度な戦略によって、テスト待機時間を短縮し、より多くの時間を優れたソフトウェア開発に充てることが可能となる。