目次
- 目的
- E2Eテストのメリデメ
- 導入
- Q & A
- 続けていくために
目的
- 自信を持ってリリースできるようになること
- 変更失敗率を下げる
- バグ発生時にMTTR(Mean Time To Recovery)を短縮する
- レビュー時に自動テストの内容を踏まえて確認することでレベルを上げる
- バグを起こしにくいコードを作る
E2Eテストのメリデメ
導入して感じたメリット
- 全体に関わるようなnpmパッケージのアップデートの際に一通りのチェックができる
- 例えばwebpackやatomicコンポーネントで使用しているライブラリなどをアップデートした際に、全体のUIが意図せず変わっていないかのテストを行うのはかなり大変
- 権限によって表示の有無が変わるようなUIのチェックが簡単にできる
- 開発中いちいちユーザーを変えてログインしてチェックは結構面倒臭い
- ページをReactに置き換える場合に、テストを記述しておくことで動作確認の信頼性を上げることができる
- シナリオテストがあれば、それを走らせるだけでサービスの主要な部分のチェックだけでなく、どういうサービスなのかを追うことができるので新しくはいるメンバーのキャッチアップの手助けになる
デメリット
- 実行のコストが大きい
- 自動で実行されるような環境を構築しておかなければすぐにサボるようになってしまう。
=> サービスのクリティカルな一連の操作に関して、一つでも失敗すると影響が大きい処理についてのシナリオを書いておけば、デプロイによるな大きなミスは避けられるのでそこだけでも必ず実行しておくようにすれば良さそう
導入
$ npm install -D cypress eslint eslint-plugin-cypress
$ npm run cypress open
ディレクトリ構造
.
├── fixtures
│ └── xxx.csv
├── integration
│ ├── xxx_spec.js
│ └── xxx_spec.js
├── plugins
│ └── index.js
├── support
│ ├── commands.js
│ ├── index.d.ts
│ └── index.js
└── tsconfig.json
- fixtures/にアップロード用のCSVやメディアのファイルを置いておく
- integration/にテストを書いていく
- support/によく使う処理をコマンド化して書いておく(ex: ログインとか)
Q & A
テスト時間を短縮の工夫
基本はベストプラクティスに沿って不要なcy.wait()を入れないなど、遅くならないようにする工夫はありますが、テストケースが増えればそれだけ時間がかかるのはある程度覚悟が必要です。
管理画面の全テストケースで毎回ログイン処理を記述していく必要はあるか
E2Eテストはただでさえ壊れやすいものなので、テスト間の依存関係はできるだけ減らすことが重要です。なのでログインは毎回行う方が良いです。テスト実行中に何度も行う必要がある処理は、APIを直接叩くようなコマンドを書いておけば実行時間を減らすことが可能です。
逆に、毎回ログイン画面にアクセスしてユーザー名とパスワードを入力して遷移するテストを行うというような「そのテストの実行がリリースの自信の向上に繋がらない」事態も避けるべきです。
E2Eテストの導入前に読んでおいて役に立つ書籍やブログなど
cypressのドキュメントは使い方ももちろんですが、思想やテストの書き方とそのメリデメなどもまとまっているので余力があるなら全体を通して読むと良いと思います。ただ、チームメンバーでベストプラクティスだけは読み合わせてから始めた方がスムーズに進むとは思います。
Cypress のテストのためのサーバをモックできるか?
可能ではありますが、テストは自信を持ってリリースするための手段なので、どの部分をモックにするかなどは慎重に考慮する必要があり、クリティカルパスに関しては、きちんとサーバーと通信するようなコードを書くと良いと思います。
E2Eテスト専用のユーザを用意するのが良さそうか
各権限を持っているテスト用のユーザーは作成する必要があります。
CI環境の構築について
テストを続けていくために
- テストを書く(コスト: 低)
- どういうテストが必要かは書いてみて初めて気づくことも多い
- githubのPRテンプレートに入れてみる(コスト: 低)
- テストだけのPRを作成してみる
- 機能を実装したら通るはずのテストを先に書いておく
- CI環境を作る(コスト: 高)
- 完全なものを作るのは難しいので、とりあえずトリガーだけ作るところから初めてみたりする