【ITニュース解説】Unmasking the Ghost in the Machine: How a Translation API Error Nearly Broke Our Cypress E2E Tests

システム開発において、アプリケーションがユーザーと同じように正しく機能するかを確認するエンドツーエンドテスト（E2Eテスト）は非常に重要である。これはシステム全体の連携を確認するテスト手法だ。私たちのチームは、企業の基幹システム（ERPシステム）のテストにCypress.ioというツールを使用していたが、ある時、多くのE2Eテストが突然失敗し始めた。普段は成功を示す「グリーン」状態が、一瞬にしてエラーを示す「レッド」状態になったのだ。

この状況で特に困惑したのは、実際のブラウザでアプリケーションを手動で操作すると、何の問題もなく完全に動作していることだった。UIも正常に表示され、多言語対応も機能していた。エラーは、Cypressによる自動テスト実行時のみに発生していた。

具体的な症状としては、UIに「ダッシュボード」ではなく「dashboard.title」のように、翻訳前の「翻訳キー」がそのまま表示されるようになった。これは、アプリケーションが翻訳データを正しく読み込めていないことを示唆している。さらにCypressのネットワークログを調べると、「LoadTranslationFile」という翻訳データを取得するAPIがエラーを起こしていることが判明した。エラーメッセージには「Failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING 200 (OK)」や「Error: Parse Error: Expected HTTP/」といった内容が表示された。同時に、SVGアイコンやPNG画像といった静的なアセットも「404 Not Found」エラーで読み込めなくなっていた。

テストを担当するエンジニアは、まずCypress側の問題を疑い、様々な対策を試みた。アプリケーションのデフォルト言語はアラビア語だが、テストでは英語を使用するように設定していたため、言語設定の競合が起きている可能性を考えた。そこで、Cypressの onBeforeLoad フックを使って、ブラウザの言語設定を英語に強制するなど、いくつかの処理を導入した。また、Cypressのネットワーク処理の不安定さを疑い、cy.intercept コマンドで翻訳APIの呼び出しを監視し、特定のタイミングで待機する処理を強化した。CypressのコマンドチェーンにおけるPromiseの扱いに問題がないかも見直したが、これらの修正を施しても、翻訳データの読み込みエラーや静的アセットの404エラーは解消されなかった。このことから、問題はCypressがリクエストを送信する方法ではなく、サーバーから受け取るレスポンス自体にある可能性が高いと判断された。

特に重要な手がかりとなったのは、「ERR_INCOMPLETE_CHUNKED_ENCODING」というエラーが「200 (OK)」という成功を示すHTTPステータスコードを伴っていた点だった。これは、リソースが見つからないのではなく、リソースは存在するが、サーバーから送られてきたデータが不完全であるか、正しく解析できない形式であることを意味する。この問題の根源は、サーバー側でのHTTP通信の仕組み、特に「Chunked Encoding（チャンク転送エンコーディング）」と「Gzip圧縮」の組み合わせにあった。Chunked Encodingは、サーバーがレスポンスの全体のサイズを事前に知らなくても、データを小さな塊（チャンク）に分けて順次送信する方式である。Gzip圧縮は、レスポンスデータを圧縮して転送速度を向上させるために広く使われる技術だ。現代のウェブブラウザは、これらの通信においてわずかな不整合があったとしても、寛容に処理してデータを表示できる能力を持つ。しかし、Cypressの内部にはNode.jsを基盤とするプロキシが組み込まれており、このプロキシはHTTPプロトコルの仕様に対してブラウザよりも厳格に振る舞うことが判明した。サーバーから送られてくるレスポンスが、チャンクのサイズが誤っていたり、終端を示す記号が欠けていたりするなど、わずかにHTTPプロトコルに違反する形式だった場合、Cypressのプロキシはそのレスポンスを正しく再構築できず、エラーを発生させていたのだ。静的アセットの404エラーも同様に、NginxなどのウェブサーバーにおけるURLの書き換えルールやエイリアスの設定が、Cypressのプロキシを経由した場合に正しく機能せず、ファイルが見つからないと判断されていた可能性が高い。つまり、問題はフロントエンドのアプリケーションやCypressのテストコードではなく、バックエンドのAPIサーバー、またはそのAPIをホストしているインフラストラクチャの側で、特定のレスポンスの生成や配信方法に不具合があったことが原因だと結論付けられた。

この問題の解決には、テストエンジニアだけでは対応できないため、バックエンド開発チームやインフラを管理するDevOpsチームとの連携が不可欠だった。テストエンジニアは、テストが失敗している具体的な状況、Cypressのネットワークログやコンソールログの証拠、そしてエラーがサーバー側の問題を示している理由を明確にまとめた報告書を作成し、関係者全員に共有した。これにより、バックエンドチームには翻訳APIのレスポンス生成、特にChunked EncodingとGzip圧縮の設定を確認してもらい、DevOpsチームにはウェブサーバーの設定やURL書き換えルールなどを調査してもらうよう依頼した。

サーバー側の恒久的な修正には時間がかかる見込みだったため、その間もテスト自動化を継続できるよう、Cypress側で一時的な回避策を導入した。このワークアラウンドは、問題のあるAPI通信をCypressの機能で模擬的に処理するというものだ。まず、実際のブラウザの開発者ツールを使って、正しく翻訳データを取得できた時のAPIレスポンスをJSONファイルとしてキャプチャし、Cypressの「フィクスチャ」としてローカルに保存した。次に、Cypressの cy.intercept コマンドを使用して、アプリケーションが翻訳APIにリクエストを送る際に、実際のサーバーからのレスポンスを待たずに、事前に保存しておいたフィクスチャのJSONデータを返すように設定した。これにより、サーバーからの不完全なレスポンスを受け取ることを避け、テストが翻訳データを正しく読み込んだかのように振る舞うことが可能になった。静的アセットの404エラーについても同様に、cy.intercept で問題のあるリクエストを捕捉し、小さな透明な画像データを返すように設定することで、エラーを回避した。これらのインターセプト設定は、アプリケーションの特定のモジュールにナビゲートする共通のコマンドに組み込まれ、初期の言語設定なども統合された。これにより、テストスイート全体でこのワークアラウンドが適用され、E2Eテストは再び正常に実行できるようになり、全てのテストが「グリーン」状態に戻った。

この経験から、いくつかの重要な教訓が得られた。E2Eテストは、アプリケーションの機能確認だけでなく、システムの基盤となるインフラストラクチャに潜む、手動テストでは発見しにくい問題の早期発見にも役立つ「早期警告システム」として機能するという点だ。また、Cypressのようなテストツールは、一般的なウェブブラウザとは異なる内部動作（特にプロキシの動作）を持つため、その特性を理解しておくことが重要である。この違いが、今回のようなサーバー側のプロトコル違反を露呈させるきっかけとなった。さらに、このような複雑な技術的問題は、品質保証、バックエンド開発、DevOpsといった複数の専門チームが密接に連携し、明確な証拠に基づいて情報共有と調査を進めることで初めて解決できることを再認識した。そして、バックエンドAPIが不安定な場合や、テスト環境との相性が悪い場合に、Cypressのフィクスチャを使った「モック（模擬応答）」が、テストの安定性を保ち、開発プロセスを滞らせないための非常に強力な手段となることを実践的に学んだ。サーバー側の恒久的な修正は現在も進行中だが、これらのCypress側のワークアラウンドによって、テスト自動化パイプラインは安定稼働し、システムの品質保証に貢献し続けている。