E2Eをやってみて感じたこと
E2Eテストとは
- いわゆるシナリオテスト
- User Interface Testとも呼ばれる
- システム全体を通してテストをおこなう
- ユーザと同じようにブラウザを操作し挙動が期待通りになっているか確認する
簡単な具体例
- ログインページの場合
- ログイン画面を表示
- メールアドレス/IDを入力
- パスワードを入力
- ログインボタンを押下
- ログイン後のトップページに遷移していること
特徴
- テストとしては上位レベル（難易度が高いとかそういう話ではない）
- フィードバックが遅い（作るのにも時間かかるし実行に時間がかかるからなぁ）
- 壊れやすい（UIテストやしHTML変えられたら死ぬ）
- ユニットテストとは真逆
- よく語られるピラミッド図
- 上に行くほど遅く、コストが高い
- 不安定
なぜ不安定になるのか
- 外部依存
- 通信
- ネットワーク
- データベース
- ファイル
- デザイン変更
- 通信
今まで通っていたテストがすべて失敗する
不安定なE2Eテストがもたらす悪影響
- 修正や調整などのコストがかかる
- テストが落ちることを前提に考えてしまうようになる
- ネットワーク
- 通信待ちでテストがタイムアウトした場合
例）大きなファイルのダウンロード処理
環境依存しがち →それってもうテストする意味ないよね
テストの処理を見直す必要がある
例外を想定してユーザに通知
- 通信待ちでテストがタイムアウトした場合
- ネットワーク
不安定なE2Eテストに対する対処法
- テストを書き直す
そのシナリオが正しいか、テスト設計やコーディング自体に改善点はないか確認する - ピラミッドの下層へ
フィードバックも早く安定的に動作するユニットテストで担保できないか検討する
すべての項目をE2Eでやる必要はなく、メリデメを考慮して設計を行う - テストの価値を見極める
全てのユースケースを洗い出し自動テストを安定的に行うのは、コストが高くあまり現実的ではない
不安定なものは捨て、手動テストすることを検討する
まとめ
なんかちょっとマイナス要素多めの記事になってしまいましたが、
「じゃあE2Eやらなきゃいいじゃん」ではなく
メリット・デメリットをしっかり理解した上で導入することが大切だと思います。
テストピラミッドを意識して、テストの実装方針を決める。
単テで補えるところは単テで実施し、E2Eが必要なところはE2Eで実施し、手動で行うところは手動で行う。
何事も行き当たりではなく設計、検討することが大切だと感じました。
