💡

GaugeでE2Eテストを書く時に意識するポイント

2023/10/29に公開

TDD

はじめに

私は仕事でもプライベートでも開発時のE2EテストでATDD（受け入れテスト駆動開発）を実践しています。

この手法は、開発開始前に受け入れ基準を明確にすることで、要求と実装のギャップを最小限にし、品質を向上させることを目的としています。
そして、ATDDを実践する際に使用するツールの選択は、その効果を最大限に引き出すための鍵となります。

その中で、Gaugeはそのシンプルさと強力な機能で多くの開発者やQAエンジニアから支持を受けているツールのひとつです。

Gaugeとは

https://gauge.org/

Gaugeに関してはUzabaseのブログが充実しているのでそちらに譲ります

開発の流れ

実装の流れの一例として以下のようなものが挙げられます

デザイナーがFigmaなどでデザインを作成
PdMがFigmaなどのデザインからGaugeのspecで仕様書を作成
開発者が仕様書（Gaugeのspecファイル）をもとにテストを作成

create-e2e-develop-cycle

私が所属しているチームでは普段から上記で挙げたプロセスを繰り返す開発をしています。

最初は慣れるのに時間がかかると思うので、大変に感じますが、ATDDに愚直に取り組むことで品質を保ちながらスピーディな開発をすることができます。

読みやすいMarkdownを書く

以下にあげる点を意識することでGaugeを使うことのメリットを最大限享受することができます。

テスト仕様書であることを意識する

私が所属しているチームではアジャイルのプラクティスのひとつであるXPを取り入れています。

XPのプラクティスの中に以下のようなものがあります

包括的なドキュメントよりも動くソフトウェアを

これはドキュメントを書かなくても良いということではなく、過度なドキュメントを作成する必要はなく、正しく動くソフトウェアの方が大事だということを言っています。

Gaugeを使うことで、specファイルでドキュメント（仕様書）を書きつつ、それに合わせてE2Eテストを行うことができます。
必要最低限のドキュメントから、それを元に正しく動くソフトウェアを作成する開発を行っています。

ここからは、以下のようなシンプルなユーザーのログインを例に説明していきます。

読み手が誰なのかを意識する

上記で挙げた通りGaugeのspecファイルは仕様書になります。
そのため、specファイルの読み手はエンジニアだけでなく、PM/PdM/サポートの方々も対象になります。

なので、以下のような記述はエンジニア目線で描かれており、仕様書としては適切ではありません。

# ログイン

## メールアドレスとパスワードでログインすることができる
* ログイン画面に遷移する
* data-testid="loginFormEmail"に"test@example.com"と入力する
* data-testid="loginFormPassword"に"Test123"と入力する
* "ログイン"ボタンをクリック
* URLに"/home"が含まれている

ひとつずつ直していきます

主語を正しく定義する

## メールアドレスとパスワードでログインすることができる

こちらは誰がどこからログインしたかがわかりません。E2Eを実行するユーザーの前提条件を明記しないと仕様書としては不十分です。この場合、登録済みでないユーザーの場合ログインすることはできません。また、ログインすることができる画面が複数ある場合があります。

あとメールアドレスとパスワードでと書かれていますが、認証方法もSSOやパスキーなど様々あるので、どの方法でログインするかも明記するとよりわかりやすいものになります。

正しく修正したものが以下になります。

## 登録済みユーザーはログイン画面からメールアドレスとパスワードでログインすることができる

実装の漏洩

* data-testid="loginFormEmail"に"test@example.com"と入力する

こちらは完全に実装が漏れ出ています。サポートの方などがこの**data-testid="loginFormEmail"**の仕様を知る必要があるでしょうか？
正しく修正したものが以下になります。

* フォームの"メールアドレス"に"test@example.com"と入力する

このステップはとても汎用性が高く、テストの具体の実装ではform内にあるlabelから取得しています。
そのため入力フォームが画面上に複数ある場合には一意に定まらない可能性があります。
この場合、汎用性は損なわれますが、以下のように書くこともできます。

* ログインフォームの"メールアドレス"に"test@example.com"と入力する

遷移後のアサートが曖昧

* URLに"/home"が含まれている

サービス初期は良いですが、画面に具体的な名前があることで他チームやサポートの方々とのコミュニケーションが楽になります。

またURLが変わった場合にアサートしている箇所を全て変更しなければいけません。そのため画面遷移後の画面は具体的にしておくほうが良いです。

* ホーム画面が表示されている

このステップの実装としてURLに/homeが含まれているかどうかのアサートでも良いと思います。

最終的に以下のようなspecファイルになります。

# ログイン

## 登録済みユーザーはログイン画面からメールアドレスとパスワードでログインすることができる
* ログイン画面に遷移する
* フォームの"メールアドレス"に"test@example.com"と入力する
* フォームの"パスワード"に"Test123"と入力する
* "ログイン"ボタンをクリック
* ホーム画面が表示されている

重複するものはテーブル形式にする

アカウントの入力した内容によってエラー内容が変わるケースの一覧をテストするものがあるとします

# ログイン時のバリデーション

## ユーザーは不正なメールアドレスとパスワードでログインした際に正しいエラーメッセージが表示されることを確認することができる
* ログイン画面に遷移する
* フォームの"メールアドレス"に"test@example.com"と入力する
* フォームの"パスワード"に"Test123"と入力する
* "ログイン"ボタンをクリック
* フォームのエラーメッセージ"登録されているデータはありません"が表示される
* フォームの"メールアドレス"に"test.sample@example.com"と入力する
* "ログイン"ボタンをクリック
* フォームのエラーメッセージ"不正なメールアドレスです"が表示される
* フォームの"パスワード"に"test"と入力する
* "ログイン"ボタンをクリック
* フォームのエラーメッセージ"正しいパスワードを入力してください"が表示される

このようになっていても正しいのですが、仕様書としては少し見づらいかもしれません。さらに今は3パターンですが、数と組み合わせが増えるにつれてさらに可読性が悪くなっていきます。そのためもっと見やすくなるように修正していきます。

Gaugeにはテーブルテストの機能があるのでそれを使用します。

# ログイン時のバリデーション

|email|password|message|
|-|-|-|
|test@example.com|Test123|登録されているデータはありません|
|test.sample@example.com|Test123 |不正なメールアドレスです|
|test@example.com|test|正しいパスワードを入力してください|

## ユーザーは不正なメールアドレスとパスワードでログインした際に正しいエラーメッセージが表示されることを確認することができる
* ログイン画面に遷移する
* フォームの"メールアドレス"に<email>と入力する
* フォームの"パスワード"に<password>と入力する
* "ログイン"ボタンをクリック
* フォームのエラーメッセージ<message>が表示される

このように組み合わせをテーブル形式に修正することで可読性が上がります。組み合わせが追加された場合でもテーブルに一行追加するだけで済みます。

まとめ

Gaugeでspecファイルを作成する際には読み手を意識し、エンジニアだけでなく他の関係者も考慮に入れることが重要です。
また、Gaugeを使用したE2Eテストを効果的に行うために、受け入れテスト駆動開発（ATDD）の手法を中心に考えることが大切です。
開発前に受け入れ基準を設定し、Gaugeのspecで仕様書を作成する手順を踏むことで品質を保ちつつ最小限のドキュメントでスピーディに開発をすることができます。