「Cypressとは？」と考えている方や、E2Eテストの自動化を始めたいけれど何から手をつければ良いか分からない開発者の方へ。本記事では、モダンなE2EテストツールであるCypressの基本から、具体的な使い方、応用テクニックまでを初心者にも分かりやすく徹底解説します。Cypressが多くの開発者に選ばれる理由は、簡単なセットアップと「タイムトラベル」に代表される優れたデバッグ機能により、これまでのテスト自動化における不安定さや複雑さを解消し、開発者体験を劇的に向上させる点にあります。SeleniumやPlaywrightとの比較を通じて、Cypressがなぜ強力なのかを理解し、今日からテスト自動化の一歩を踏み出しましょう。
Cypressとは E2Eテストを革新する自動化ツール
Cypress（サイプレス）とは、モダンなWebアプリケーション開発のために設計された、JavaScriptベースのフロントエンド向けE2E（End-to-End）テスト自動化フレームワークです。開発者がより快適に、そして効率的にテストを書けるように「開発者体験（DX）」を最優先に考えて作られており、テストのセットアップから実行、デバッグまでの一連のプロセスを単一のツールで完結できる「オールインワン」のソリューションとして、世界中の開発者から高い支持を得ています。
従来のテストツールが抱えていた複雑な環境構築や不安定なテスト実行といった課題を、独自のアーキテクチャによって解決し、高速で信頼性の高いテストを実現します。
そもそもE2Eテストとは何か
Cypressを理解する上で、まずE2Eテスト（エンドツーエンドテスト）が何かを知っておく必要があります。E2Eテストとは、アプリケーションの「始まりから終わりまで」の全体の流れを、実際のユーザーと同じ視点・操作で検証するテスト手法です。例えば、ECサイトであれば「トップページを開き、商品を検索し、カートに追加して、購入手続きを完了する」といった一連のユーザーストーリー全体が正しく機能するかを確認します。
個々の部品（コンポーネント）を検証する単体テストや、部品同士の連携を確認する結合テストとは異なり、E2Eテストはデータベース、ネットワーク、外部API連携など、システム全体を含めた動作を保証する目的で行われます。これにより、ユーザーにアプリケーションを届ける前の最終的な品質担保や、機能改修による意図しない不具合（リグレッション）の発生を防ぐ上で非常に重要な役割を担います。
Cypressが持つ独自のアーキテクチャ
Cypressが他の多くのテストツールと一線を画す最大の理由は、その独自のアーキテクチャにあります。代表的なテストツールであるSeleniumが、WebDriverというAPIを介してブラウザを「外部から」遠隔操作するのに対し、Cypressはブラウザと「同じ実行ループ内」でテストコードを直接実行します。
このアーキテクチャにより、Cypressはテスト対象のアプリケーションにネイティブにアクセスできます。ネットワーク層を介さずに直接DOMを操作したり、ネットワークリクエストを監視・改変したりすることが可能です。その結果、外部から操作する際に生じがちな通信の遅延やタイミングの問題が解消され、非常に高速で安定したテスト実行が実現されるのです。この構造が、後述するタイムトラベル機能などの強力なデバッグ体験も可能にしています。
Cypressの主な機能と特徴
Cypressは「オールインワン」を謳っており、テストに必要な多くの機能が最初から組み込まれています。これにより、開発者は複数のライブラリを組み合わせる手間なく、すぐにテスト作成に集中できます。以下にCypressの主な機能と特徴をまとめました。
| 機能・特徴 | 概要 |
|---|---|
| タイムトラベルデバッグ | テスト実行中の各ステップのDOMスナップショットを記録します。コマンドログをクリックするだけで、その時点のアプリケーションの状態を視覚的に確認でき、デバッグが非常に容易になります。 |
| 自動待機（Automatic Waiting） | コマンド実行前に、対象の要素が表示されたり操作可能になったりするのを自動で待機します。これにより、タイミング問題による不安定なテスト（Flaky Test）を大幅に削減できます。 |
| リアルタイムリロード | テストコードを保存すると、Cypressのテストランナーが自動で変更を検知し、テストを再実行します。これにより、トライ＆エラーのサイクルを高速に回すことができます。 |
| ネットワーク制御 | ネットワークリクエストを監視し、レスポンスを書き換えたり（スタブ化）、APIサーバーがなくてもテストを進めたりすることが容易に行えます。 |
| スクリーンショットとビデオ録画 | テストが失敗した際のスクリーンショットや、テスト実行全体のビデオを自動で記録する機能が組み込まれています。CI/CD環境での原因特定に役立ちます。 |
| 統合されたライブラリ | アサーション（検証）ライブラリのChaiや、モック・スタブライブラリのSinon.JSなどが初めから統合されており、追加のインストールなしですぐに利用できます。 |
Cypressを利用するメリットとデメリット
Cypressは、そのモダンなアーキテクチャと開発者フレンドリーな設計により、多くのメリットを提供します。一方で、導入前に知っておくべきデメリットや技術的な制約も存在します。ここでは、Cypressを採用する際に考慮すべき利点と注意点を詳しく解説します。
メリット1 簡単なセットアップと直感的な操作性
Cypressが多くの開発者から支持される最大の理由の一つは、その導入の手軽さです。Seleniumのような従来のテストフレームワークでは、WebDriverやブラウザごとのドライバを個別にインストールし、パスを通すといった煩雑な環境構築が必要でした。しかし、Cypressはnpmやyarnといったパッケージマネージャを使い、コマンド一つでプロジェクトに必要なすべてをインストールできます。
npm install cypress --save-dev
このコマンドを実行するだけで、テスト実行に必要なツール一式が揃い、すぐにテストを書き始められます。このシンプルなセットアップは、プロジェクトへのE2Eテスト導入のハードルを大幅に下げ、開発チーム全体の生産性向上に貢献します。
また、Cypress Test Runnerという専用のGUIツールが提供されており、テストの実行状況をリアルタイムで視覚的に確認できる点も大きな魅力です。画面の左側にテストコードのコマンドログ、右側にアプリケーションの実際の表示が並ぶため、どのコマンドで何が起きているのかを直感的に把握できます。この分かりやすさは、特にE2Eテスト初心者にとって学習コストを低く抑える助けとなります。
メリット2 タイムトラベル機能による優れたデバッグ体験
テストが失敗した際のデバッグのしやすさも、Cypressが際立っている点です。Cypress Test Runnerには「タイムトラベル」と呼ばれる強力な機能が搭載されています。これは、テスト実行中に記録された各コマンドの時点でのアプリケーションの状態（DOMスナップショット）を、後からいつでも確認できる機能です。
テストが失敗した場合、コマンドログから失敗した箇所をクリックするだけで、その瞬間の画面がどうなっていたのか、なぜ要素が見つからなかったのか、といった原因を視覚的に特定できます。さらに、その時点でのコンソール出力やネットワークリクエストも確認できるため、デバッグ作業が劇的に効率化します。従来のように、エラーログだけを頼りに原因を推測したり、デバッグのためにコードを何度も修正して再実行したりする必要はほとんどありません。この優れたデバッグ体験は、開発サイクルを高速化し、品質の高いアプリケーションを迅速にリリースするための大きな武器となります。
メリット3 自動待機機能によるテストの安定化
E2Eテストにおいて頻繁に問題となるのが、非同期処理や画面描画の遅延によってテストが不安定になる「Flaky Test（フレークなテスト）」です。Cypressは、この問題を解決するために「自動待機（Automatic Waiting）」機能を標準で備えています。
Cypressは、要素をクリックしたりテキストを入力したりするコマンドを実行する前に、その対象要素が画面に表示され、操作可能な状態になるまで自動的に待機します。例えば、cy.get('.btn').click() というコマンドは、`.btn` という要素が出現するまで最大で設定されたタイムアウト時間（デフォルトは4秒）まで待ち続けます。この仕組みにより、開発者がテストコード内にsleepのような固定時間の待機処理や、複雑な待機条件を記述する必要がほとんどなくなり、テストの信頼性が大幅に向上します。
結果として、テストコードはよりシンプルで可読性が高くなり、メンテナンスも容易になります。自動待機機能は、不安定なテストに悩まされることなく、本質的なアプリケーションのロジック検証に集中できる環境を提供してくれます。
知っておくべきCypressのデメリットと限界
Cypressは非常に強力なツールですが、万能ではありません。その独自のアーキテクチャに起因するいくつかのデメリットや制約が存在します。導入を決定する前に、これらの点を正確に理解しておくことが重要です。
| デメリット/限界 | 詳細な説明 |
|---|---|
| 複数タブ・ウィンドウの操作不可 | Cypressのテストは単一のブラウザタブ内で実行されるという設計思想のため、target="_blank"で開かれる新しいタブやウィンドウを直接操作することはできません。テストコード側でリンクのtarget属性を削除して同じタブでページ遷移させる、といった回避策が必要になる場合があります。 |
| 同一オリジンポリシーの制約 | セキュリティ上の理由から、テスト中に異なるオリジン（ドメイン、プロトコル、ポートのいずれかが違うURL）にまたがる操作を直接行うことには制約があります。ただし、cy.origin()コマンドを使用することで、異なるオリジンのページをテストすることも可能になっています。 |
| 限定的なブラウザサポート | Seleniumが非常に多くのブラウザをサポートしているのに対し、Cypressが公式にサポートしているブラウザはChromeファミリー（Chrome, Edge, Electron）とFirefoxに限られます。Safariや古いバージョンのInternet Explorerでのテストは実行できません。ただし、現代的なWeb開発においては主要なブラウザをカバーできていると言えます。 |
| iFrameの限定的なサポート | iFrame内の要素を操作することは可能ですが、Seleniumなどと比較するとやや複雑な記述が必要になる場合があります。プラグインを利用することで操作性を向上させることも可能です。 |
これらのデメリットは、プロジェクトの要件によっては大きな問題にならないこともありますが、特に複数のドメインを横断する複雑なユーザーフローや、幅広いブラウザでの互換性テストが必須となる場合には、他のツール（SeleniumやPlaywrightなど）との比較検討が必要になるでしょう。
Cypressと他のテストツールとの違いを比較
Cypressは非常に強力なE2Eテストツールですが、プロジェクトの要件やチームのスキルセットによっては、他のツールが適している場合もあります。ここでは、E2Eテストの分野で長年の実績を持つ「Selenium」と、近年急速にシェアを伸ばしているモダンなツール「Playwright」を取り上げ、Cypressとの違いを詳しく比較します。それぞれのツールの特徴を理解し、最適な選択を行うための判断材料としてご活用ください。
Cypress vs Selenium どちらを選ぶべきか
Seleniumは、WebDriverというプロトコルを通じてブラウザを外部から操作する、古くから存在するデファクトスタンダードのテスト自動化フレームワークです。一方、Cypressはブラウザ内部でテストコードを直接実行する独自のアーキテクチャを採用しています。この根本的な違いが、両者の特徴を大きく分けています。
まずは、それぞれの主な違いを比較表で確認してみましょう。
| 比較項目 | Cypress | Selenium |
|---|---|---|
| アーキテクチャ | ブラウザ内でテストコードを直接実行 | WebDriverを介してブラウザを外部から操作 |
| セットアップ | 非常に簡単。コマンド一つで開始可能 | WebDriverのセットアップなど、比較的複雑 |
| テストの安定性 | 自動待機機能が組み込まれており、安定しやすい | 待機処理を明示的に記述する必要があり、不安定になりやすい（Flaky Test） |
| デバッグ機能 | タイムトラベル機能など、非常に強力で直感的 | IDEのデバッグ機能に依存。エラー原因の特定が難しい場合がある |
| 対応言語 | JavaScript / TypeScript | Java, Python, C#, Ruby, JavaScriptなど多言語に対応 |
| 複数タブ/ウィンドウ | 直接的な操作はサポートしておらず、工夫が必要 | 標準でサポート |
Cypressが適しているケース
Cypressは、特に開発者体験（DX）を重視する場合に最適な選択肢です。以下のような状況で真価を発揮します。
- フロントエンド開発者がテストコードを記述する場合
- JavaScriptまたはTypeScriptで開発環境が統一されているプロジェクト
- テストを書きながら開発を進めるアジャイルな開発スタイル
- SPA（Single Page Application）のテストが中心である場合
- 迅速なフィードバックと視覚的で分かりやすいデバッグ環境を求めている場合
Seleniumが適しているケース
Seleniumは、その歴史と実績から、より広範で複雑な要件に対応できる柔軟性を持っています。
- QA専門チームがテストを担当し、JavaやPythonなど多様な言語スキルを活用したい場合
- Safariやレガシーブラウザなど、幅広いブラウザでのテストカバレッジが必須の場合
- 複数のタブやウィンドウをまたぐ複雑なユーザーシナリオをテストする必要がある場合
- 長年の実績と巨大なコミュニティによる豊富な情報を重視する場合
Cypress vs Playwright モダンなツールの比較
Playwrightは、Microsoftによって開発されている比較的新しいE2Eテストツールです。Cypressと同様にモダンなアーキテクチャを採用し、開発者フレンドリーな機能を提供しつつ、Cypressが苦手としていた部分をカバーしているのが特徴です。CypressとPlaywrightは、現代的なE2Eテストツールを選ぶ際の主要な比較対象となります。
両者の特徴を比較してみましょう。
| 比較項目 | Cypress | Playwright |
|---|---|---|
| 開発元 | Cypress.io | Microsoft |
| ブラウザ対応 | Chrome, Firefox, Edge, WebKit (限定的) | Chromium (Chrome, Edge), Firefox, WebKit (Safari) を完全にサポート |
| 対応言語 | JavaScript / TypeScript | TypeScript / JavaScript, Python, Java, .NET |
| 並列実行 | Cypress Cloud (有償) での並列実行に強み | 標準機能 (Shard) として強力な並列実行をサポート |
| 複数タブ/ウィンドウ | 非対応 (工夫が必要) | 標準でフルサポート |
| デバッグとGUI | タイムトラベル機能を持つ専用のGUIが非常に強力 | Trace Viewerという強力なGUIデバッグツールを提供。Codegenによるコード自動生成も便利 |
Cypressが適しているケース
Playwrightと比較した場合、Cypressの最大の強みは、そのインタラクティブなテストランナーとデバッグ体験にあります。テストを「書き、見て、デバッグする」というサイクルを非常に高速に回せるため、テスト駆動開発（TDD）やビヘイビア駆動開発（BDD）との相性が抜群です。
- テスト作成時の視覚的なフィードバックとデバッグのしやすさを最優先したい場合
- テストコードを書くこと自体の学習コストを下げ、開発チーム全体でテストに取り組む文化を醸成したい場合
- 豊富なプラグインエコシステムを活用したい場合
Playwrightが適しているケース
Playwrightは、Cypressの利便性とSeleniumの広範な対応力を併せ持つ、オールラウンダーなツールと言えます。特に、クロスブラウザ対応の厳密さが求められる場合に強力です。
- WebKit（Safari）エンジンを含む、主要なすべてのブラウザエンジンで一貫したテストを行いたい場合
- 複数タブ、複数オリジン、iframeなどを扱う複雑なテストシナリオが多い場合
- Pythonや.NETなど、JavaScript/TypeScript以外の言語でテストを書きたい場合
- テストの実行速度と並列処理性能を重視する場合
Cypressの始め方 インストールから初期設定まで
Cypressの強力な機能を体験するためには、まずお使いの開発環境にCypressをセットアップする必要があります。この章では、Cypressのインストールからプロジェクトの初期設定、そして基本的な起動方法までを、初心者の方にも分かりやすくステップバイステップで解説します。手順通りに進めるだけで、誰でも簡単にCypressを始めることができます。
必要な動作環境と準備
Cypressをインストールする前に、お使いのコンピュータが以下の動作環境を満たしているか確認してください。Cypressは主要なオペレーティングシステムに対応しており、特別な準備はほとんど必要ありません。
| 項目 | 要件・推奨 |
|---|---|
| OS | macOS 10.9以上 (64-bitのみ)、Linux (Ubuntu, Fedora, Debianなど、64-bit)、Windows 7以上 (64-bit) |
| Node.js | Cypressのバージョンによって要求されるNode.jsのバージョンは異なりますが、公式でサポートされているLTS（長期サポート）版の利用を強く推奨します。 |
| パッケージマネージャー | npm (Node.jsに同梱) または yarn。本記事では両方のコマンド例を記載します。 |
| コードエディタ | Visual Studio Code (VS Code)など、JavaScriptに対応したエディタがあると開発がスムーズです。 |
Node.jsがインストールされていない場合は、公式サイトからご自身のOSに合ったLTS版をダウンロードしてインストールしてください。Node.jsをインストールすると、パッケージマネージャーであるnpmも自動的に利用可能になります。
npmまたはyarnを使ったインストール手順
動作環境の準備が整ったら、いよいよCypressをプロジェクトにインストールします。Cypressはテスト対象のプロジェクトごとにローカルインストールするのが一般的です。
Step 1: プロジェクトの準備
まず、Cypressを導入したいプロジェクトのディレクトリに移動します。新しいプロジェクトを作成する場合は、以下のコマンドでディレクトリを作成し、移動してください。
mkdir cypress-test-projectcd cypress-test-project
次に、プロジェクト管理ファイルであるpackage.jsonを作成します。以下のコマンドを実行すると、対話形式の質問なしでデフォルト設定のファイルが生成されます。
npmを利用する場合:
npm init -y
yarnを利用する場合:
yarn init -y
Step 2: Cypressのインストール
続いて、Cypress本体をプロジェクトにインストールします。Cypressはアプリケーションの実行時には不要な開発時依存（devDependencies）としてインストールするのがベストプラクティスです。
npmを利用する場合:
npm install cypress --save-dev
yarnを利用する場合:
yarn add cypress --dev
このコマンドを実行すると、Cypressのパッケージがダウンロードされ、node_modulesディレクトリに格納されます。また、package.jsonのdevDependenciesセクションにCypressが追記されます。インストールには数分かかることがあります。
Cypressの起動とフォルダ構成の解説
インストールが完了したら、Cypressを起動してみましょう。初めて起動する際に、Cypressは必要な設定ファイルとフォルダ構造を自動的に生成してくれます。
Cypressの起動
プロジェクトのルートディレクトリで以下のコマンドを実行します。
npx cypress open
npxコマンドは、プロジェクト内にローカルインストールされたパッケージを実行するための便利なツールです。このコマンドを実行すると、CypressのGUIアプリケーション（Cypress App）が起動します。
初回起動時には、E2Eテストかコンポーネントテストかを選択する画面が表示されます。ここでは「E2E Testing」を選択し、設定を進めてください。すると、cypress.config.jsという設定ファイルや、テストファイルを格納するためのcypressディレクトリがプロジェクト内に自動で生成されます。
自動生成されるフォルダ構成
Cypressを起動すると、主に以下のようなフォルダとファイルが作成されます。それぞれの役割を理解しておくことで、今後のテスト開発がスムーズになります。
| フォルダ / ファイル名 | 主な役割 |
|---|---|
cypress/ | Cypress関連のファイルを格納するメインディレクトリ。 |
cypress/e2e/ | E2Eテストのスペックファイル（.cy.jsなどの拡張子を持つテストコード）を配置する場所。 |
cypress/fixtures/ | テストで使用する静的なデータ（JSONファイルなど）を格納する場所。モックデータとして利用します。 |
cypress/support/ | カスタムコマンドの定義（commands.js）や、すべてのテストで共通して読み込む処理（e2e.js）を記述する場所。 |
cypress.config.js | Cypressの全体的な設定を行うファイル。ベースURLやテストのタイムアウト時間などをここで構成します。 |
これでCypressの基本的なセットアップは完了です。次章では、この環境を使って実際にテストコードを書いていきます。
Cypressの基本的な使い方 テストコードを書いてみよう
Cypressのインストールと初期設定が完了したら、いよいよテストコードの作成に取り掛かります。この章では、テストファイルの基本的な構造から、要素の操作、結果の検証（アサーション）、そしてテストの実行方法まで、Cypressの基本的な使い方を具体的なコード例と共に解説します。初めてE2Eテストに触れる方でも、ステップバイステップで理解を深められる内容です。
テストファイルの作成と基本構文
Cypressのテストファイルは、cypress/e2eディレクトリ内に作成します。ファイル名の末尾は.cy.jsや.cy.ts（TypeScriptの場合）のようにする必要があります。例えば、login.cy.jsのように命名します。
テストコードは、JavaScriptのテスティングフレームワークであるMochaのBDD（ビヘイビア駆動開発）構文に似た形式で記述します。主にdescribe()とit()という2つの関数を使ってテストの構造を定義します。
describe('テストスイート名', () => { ... }): 関連するテストケースをまとめるグループ（テストスイート）を定義します。入れ子にすることも可能です。it('テストケース名', () => { ... }): 個別のテストケースを定義します。「〜ができること」といったように、テストの目的がわかる名前を付けます。
実際のテストコードの基本構造は以下のようになります。
この構造を理解することが、Cypressでのテスト作成の第一歩です。
要素の選択と操作を行う基本コマンド
Webアプリケーションのテストでは、「特定の入力欄に文字を入力する」「ボタンをクリックする」といったブラウザ操作が中心となります。Cypressでは、これらの操作をcyオブジェクトから始まる直感的なコマンドで実行できます。
要素を選択する最も基本的なコマンドはcy.get()です。引数にはCSSセレクタを指定し、jQueryのようにDOM要素を特定します。その後、チェーンメソッドで操作コマンドを繋げていきます。
以下は、よく使用される基本的な操作コマンドの一覧です。
| コマンド | 説明 |
|---|---|
cy.visit('[URL]') | 指定したURLのページにアクセスします。 |
cy.get('[CSSセレクタ]') | CSSセレクタに一致するDOM要素を取得します。 |
.type('[文字列]') | 選択した入力要素（input, textareaなど）に文字列を入力します。 |
.click() | 選択した要素をクリックします。 |
.select('[値]') | 選択した<select>要素の特定のオプションを選択します。 |
.check() | 選択したチェックボックスやラジオボタンをチェック状態にします。 |
.uncheck() | 選択したチェックボックスのチェックを外します。 |
.clear() | 選択した入力要素の値をクリアします。 |
これらのコマンドを使って、先ほどのログインテストを具体的に記述してみましょう。
アサーション（検証）の書き方
テスト自動化の目的は、操作を実行するだけでなく、その結果が期待通りであるかを確認することです。この「期待通りかを確認する処理」をアサーション（Assertion）または検証と呼びます。
Cypressは、アサーションライブラリのChaiを内蔵しており、.should()や.and()といったコマンドを使って自然言語に近い形で検証を記述できます。これにより、コードの可読性が大幅に向上します。
以下は、代表的なアサーションの記述方法です。
| Chainer | 説明 | 使用例 |
|---|---|---|
.should('be.visible') | 要素が画面に表示されていることを検証します。 | cy.get('.error').should('be.visible'); |
.should('not.exist') | 要素がDOM上に存在しないことを検証します。 | cy.get('.modal').should('not.exist'); |
.should('have.text', '[文字列]') | 要素のテキスト内容が指定した文字列と完全に一致することを検証します。 | cy.get('h1').should('have.text', 'ようこそ'); |
.should('contain.text', '[文字列]') | 要素のテキスト内容に指定した文字列が含まれていることを検証します。 | cy.get('p').should('contain.text', '成功しました'); |
.should('have.class', '[クラス名]') | 要素が指定したCSSクラスを持っていることを検証します。 | cy.get('button').should('have.class', 'btn-primary'); |
.should('have.value', '[値]') | 入力要素が指定した値（value）を持っていることを検証します。 | cy.get('input').should('have.value', '初期値'); |
.should('be.disabled') | 要素が無効化（disabled属性を持つ）されていることを検証します。 | cy.get('button').should('be.disabled'); |
これらのアサーションをログインテストに追加してみましょう。ログイン成功後、URLがダッシュボードに変わり、特定のテキストが表示されることを確認します。
テストの実行方法 GUIとCUI（ヘッドレスモード）
作成したテストは、2つの主要な方法で実行できます。開発中はGUI、自動化パイプラインではCUI、というように用途に応じて使い分けるのが一般的です。
| 項目 | GUIモード（インタラクティブモード） | CUIモード（ヘッドレスモード） |
|---|---|---|
| 実行コマンド | npx cypress open | npx cypress run |
| 主な用途 | テストコードの開発、デバッグ | CI/CDでの自動テスト実行、リグレッションテスト |
| 特徴 | 専用のテストランナー画面が起動テストの実行状況をリアルタイムで視覚的に確認可能タイムトラベル機能によるデバッグが強力特定のテストだけを選択して実行できる | ターミナル（コマンドライン）上で完結バックグラウンドでブラウザ（ヘッドレス）が起動しテストを実行実行結果のサマリーがターミナルに表示されるテスト失敗時のスクリーンショットや実行動画が自動で保存される |
テストコードを書いている最中はnpx cypress openでGUIを立ち上げ、操作の様子やDOMの状態を確認しながら開発を進めます。そして、完成したテストをGitHub ActionsなどのCI/CDツールに組み込む際にはnpx cypress runを使い、プッシュやマージをトリガーにテストを自動実行させる、というワークフローがCypressの基本的な活用方法となります。
Cypressをさらに活用するための応用テクニック
Cypressの基本的な使い方をマスターしたら、次はより高度で実践的なテクニックを学び、テストの品質と効率をさらに向上させましょう。ここでは、テストコードの保守性を高め、開発プロセス全体を自動化するための応用テクニックを紹介します。
カスタムコマンドでテストを効率化する
テストコードを書いていると、ログイン処理や特定フォームへの入力など、何度も同じような操作を繰り返すことがあります。このような定型的な操作を「カスタムコマンド」として定義することで、テストコードをDRY（Don’t Repeat Yourself）の原則に従った、より簡潔で可読性の高いものにできます。
カスタムコマンドの作成方法
カスタムコマンドは、プロジェクト内の `cypress/support/commands.js` ファイルに `Cypress.Commands.add()` を使って定義します。例えば、多くのテストで必要となるログイン処理をカスタムコマンド化してみましょう。
カスタムコマンドの呼び出し
定義したカスタムコマンドは、通常のCypressコマンドと同様に `cy.` から呼び出すことができます。これにより、テストの意図がより明確になります。
このように、繰り返し利用する操作を共通化することで、テストコードのメンテナンス性が大幅に向上します。
ページオブジェクトモデル（POM）で保守性を高める
アプリケーションが大規模になるにつれて、UIの変更がテストコードに与える影響も大きくなります。ページオブジェクトモデル（Page Object Model, POM）は、ページのUI要素（セレクタ）とその操作をオブジェクトとしてカプセル化する設計パターンです。これにより、UIの変更に強く、保守性の高いテストコードを構築できます。
ページオブジェクトの作成
ページごとにJavaScriptのクラスを作成し、そのページ内の要素を取得するゲッターや、要素を操作するメソッドを定義します。例えば、ログインページのページオブジェクトは次のようになります。
テストコードでの利用
テストファイルでは、このページオブジェクトをインポートして利用します。セレクタの変更があった場合でも、修正はページオブジェクトファイルのみで済み、テストコード本体を変更する必要はありません。
CI/CDツールとの連携（GitHub Actionsの例）
開発プロセスにE2Eテストを組み込む上で、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインでの自動実行は不可欠です。これにより、コードがマージされる前に、常にアプリケーション全体の動作が保証されるようになります。ここでは、代表的なCI/CDツールであるGitHub Actionsとの連携方法を解説します。
GitHub Actionsのワークフロー設定
プロジェクトのルートに `.github/workflows` ディレクトリを作成し、その中にYAML形式の設定ファイル（例: `cypress-tests.yml`）を配置します。
ワークフローの解説
このワークフローは、リポジトリにコードがプッシュされるたびにトリガーされます。`cypress-io/github-action` を利用することで、Cypressの実行環境のセットアップからテスト実行までを簡単に行うことができます。
| ステップ | 説明 |
|---|---|
| Checkout | `actions/checkout`アクションを使い、リポジトリのソースコードをCI環境にチェックアウトします。 |
| Cypress run | Cypress公式のアクションを利用してテストを実行します。`start`でアプリケーションの起動コマンドを指定し、`wait-on`でアプリケーションが応答可能になるまで待機します。`headless: true`でブラウザUIなしの高速なテストを実行します。 |
この設定により、開発者はコードをプッシュするだけで自動的にE2Eテストが実行される環境を構築でき、デグレードの早期発見や品質保証の自動化が実現します。
環境変数を活用したテスト環境の切り替え
開発環境、ステージング環境、本番環境など、複数の環境に対してテストを実行したい場合があります。Cypressでは環境変数を利用することで、テストコードを変更することなく、実行環境に応じた設定（ベースURLやAPIエンドポイントなど）を動的に切り替えることができます。
環境変数の設定方法
環境変数を設定するには、主に3つの方法があります。
| 設定方法 | 説明 | 利用シーン |
|---|---|---|
| `cypress.json` | `env`キーの中にキーと値のペアを記述します。プロジェクト全体で共有される設定に適しています。 | デフォルトのAPIエンドポイントなど |
| `cypress.env.json` | `.gitignore`に追加することで、ローカル環境固有の秘密情報（APIキーなど）を安全に管理できます。 | 個人の開発環境用の認証情報など |
| コマンドラインオプション | `–env`フラグを使って、テスト実行時に動的に値を渡します。CI/CD環境での利用に便利です。 | CI環境でベースURLを切り替えるなど |
テストコードでの利用
設定した環境変数は、`Cypress.env()`メソッドを使ってテストコード内から参照できます。
このように環境変数を活用することで、一つのテストコードで複数の環境に対応できる、柔軟で再利用性の高いテストスイートを構築できます。
まとめ
本記事では、E2Eテスト自動化ツール「Cypressとは」何か、その基本から応用までを解説しました。Cypressは、簡単なセットアップ、タイムトラベルによるデバッグの容易さ、自動待機による安定したテスト実行といった強力な特徴を持ちます。これらの理由から、特にフロントエンド開発者にとって、Seleniumに代わる有力な選択肢と言えるでしょう。開発体験を大きく向上させるCypressを、ぜひ本記事を参考に導入し、品質の高いアプリケーション開発に役立ててください。
