【ITニュース解説】From Playwright to Cypress.io: Solving 5 Real-World Testing Challenges

システムエンジニアを目指す初心者が、ソフトウェアのテストについて学ぶ上で、PlaywrightやCypress.ioといった自動テストツールは非常に重要な存在だ。これらのツールを使うことで、開発したシステムが意図した通りに動作するかを自動で確認できる。しかし、それぞれのツールには異なる特性があり、特にPlaywrightからCypress.ioへ移行する際には、いくつか知っておくべきポイントがある。この記事では、Cypress.ioを使う上でよく直面する五つの課題と、その解決策について解説する。

最初の課題は「複数ユーザーセッションの管理」だ。多くのWebアプリケーションでは、管理者ユーザーと一般ユーザーのように、異なる権限を持つユーザーが同時にアクセスしたり、役割を切り替えたりするシナリオをテストする必要がある。Playwrightでは、このような複数ユーザーのフローを簡単に扱うことができた。それは、Playwrightがブラウザのコンテキストを完全に独立させて実行できるためだ。一方、Cypress.ioは従来、一つのブラウザコンテキスト内でテストを実行する設計だったため、この点で工夫が必要だった。しかし、Cypress.ioのバージョン9.6以降に導入されたcy.session()という機能を使うことで、セッション情報を効率的に保存し、必要に応じて復元できるようになった。これにより、例えば管理者がログインした状態から一般ユーザーに切り替えるといったテストシナリオも、cy.session()を活用したログインコマンドを作成することで、スムーズに実行できる。もし一つのテストファイル内で複数の役割を切り替えるのが複雑すぎると感じる場合は、それぞれの役割に応じたテストを別のファイルに分割し、後述する並列実行の仕組みを利用することも有効な解決策となる。

二つ目の課題は「テストの並列実行による高速化」だ。テストの量が増えれば増えるほど、全体の実行時間は長くなる。これを解決するために、複数のテストを同時に実行する並列テストが重要となる。Playwright Testは、最初からworkersという仕組みを使って並列実行をサポートしており、特別な設定なしにテストを高速化できる。Cypress.ioの場合、公式に推奨されているのはCypress Dashboardという有償サービスを利用する方法だ。Cypress Dashboardを使うと、テストファイルを複数のマシンに自動で分散させて実行できるため、テスト全体の実行時間を大幅に短縮できる。これは大規模なテストスイートを持つ場合に特に効果的だ。Cypress Dashboardを使わない場合でも、CI/CD環境（例えばGitHub Actionsなど）でテストファイルを複数に分割し、それぞれのファイルを個別のコマンドとして実行することで、手動で並列実行に近い状態を作り出すことは可能だ。さらに、cypress-splitのようなコミュニティ製のツールを利用すれば、テストファイルをワーカーに均等に分割するのを自動化できるため、手動での分割よりも効率的になるだろう。

三つ目の課題は「時間のかかる処理への対応（タイムアウトの調整）」だ。Webアプリケーションの中には、データの読み込みや複雑な計算など、完了までに時間がかかる処理が存在することがある。Playwrightでは、このような場合でも、グローバルなタイムアウト設定や、個々のアクションに対するタイムアウトを簡単に調整できる。Cypress.ioのコマンドには、要素が見つからない場合などに自動的にリトライする機能が組み込まれているが、デフォルトのタイムアウト設定は比較的厳しく、例えばコマンドのデフォルトタイムアウトは4秒、ページの読み込みタイムアウトは60秒と設定されている。もしアプリケーションの処理がこれらのデフォルトタイムアウトを超えてしまう場合は、cypress.config.jsという設定ファイルで、defaultCommandTimeoutやpageLoadTimeoutといった値を変更することで、グローバルにタイムアウトを延長できる。また、特定のコマンドに対してのみタイムアウトを長くしたい場合は、そのコマンドのオプションとしてタイムアウト値を指定することも可能だ。ただし、安易にタイムアウトを長くしすぎるのではなく、要素が表示されるまで待つアサーションを適切に使うなど、スマートな待機方法を組み合わせることが、より堅牢なテストを作成するための良いプラクティスとなる。

四つ目の課題は「ファイルのアップロード」だ。Webフォームで画像やドキュメントファイルをアップロードする機能は一般的だが、これを自動テストでどう扱うかはツールによって異なる。PlaywrightはsetInputFiles()という専用のメソッドを提供しており、ファイル入力要素に対して直接ファイルを指定してアップロードできるため、非常にシンプルだ。Cypress.ioの場合、標準機能だけではファイルのアップロードを直接扱うのが少し複雑になる。そのため、cypress-file-uploadというヘルパープラグインをインストールして使うのが一般的だ。このプラグインを導入すると、attachFile()という便利なコマンドが利用できるようになり、ファイル入力要素に対してテスト用のファイルを簡単に指定できる。ドラッグアンドドロップでファイルをアップロードするようなUIの場合も、このプラグインで対応できる。テストで使用するファイルは、Cypressのテスト環境でアクセスしやすいように、通常cypress/fixtures/ディレクトリ内に配置しておくのが良い習慣だ。

最後の課題は「cy.request()とcy.intercept()の違い」だ。これら二つのCypressコマンドはどちらもネットワークリクエストに関わるが、その目的と使いどころは大きく異なるため、初心者には混乱しやすいポイントかもしれない。cy.request()は、WebアプリケーションのUIを介さずに、直接HTTPリクエストをサーバーに送信するためのコマンドだ。これは、APIのテストを行ったり、テストデータの準備（例えば、テスト前にユーザーをログイン状態にする、データベースの状態をクリーンアップするなど）を高速に行ったりするのに適している。UIのレンダリングを待つ必要がないため、テスト実行時間を短縮できる。一方、cy.intercept()は、Webアプリケーションが実際にブラウザ上で動作している最中に発生するネットワークリクエストを監視したり、途中でリクエストの内容を変更したり、あるいはサーバーからのレスポンスを偽装（モック）したりするためのコマンドだ。これは、バックエンドの挙動をシミュレートしたり、特定のネットワークリクエストが正しく行われたかを検証したりするUIテストにおいて非常に強力な機能だ。例えば、APIから取得したデータがUIに正しく表示されるかをテストする際に、cy.intercept()を使って意図的にAPIからのレスポンスを制御することで、より安定したテストを作成できる。

このように、PlaywrightとCypress.ioでは、同じようなテストの目的を達成するために異なるアプローチや機能が提供されている場合がある。Cypress.ioの設計思想や提供されている機能、そして利用可能なプラグインやベストプラクティスを理解し、これらの違いに適応することで、Playwrightでの経験を活かしつつ、高速で保守性が高く、信頼性の高いCypressテストを記述することが可能になるだろう。新しいツールに慣れるのは大変なこともあるが、これらの知識があれば、システムエンジニアとしてのスキルアップに大きく貢献するはずだ。