Motivation
上司に「E2Eテスト(ぽいの)担当して」って言われたけど、うーん、なんにもわからん
というわけで調べた
E2Eテストとは
https://martinfowler.com/articles/practical-test-pyramid.html#End-to-endTests
を読んでみた。(以下、ほぼ訳)
E2Eテスト = End to end テスト
ユーザーインターフェース(UI)を介して、デプロイされたアプリケーションをテストすること。
ソフトウエアが動作していることを確認する。
(想定: ブラウザを介したアプリケーション)
ブラウザを開いて、クリックしたり、データを入力したりして、UIを確認する。
後述のUIテストとは違うのは、End to Endで(システム全体を利用して)テストする
E2Eテストの課題
(意図せず)壊れやすい
しばしば期待しない予測不可能な理由で失敗する。この多くは実際は失敗ではなく、誤検知である。
それはブラウザの特徴や、タイミング、アニメーション、期待しないポップアップダイアログが原因である。
誤検知ばかりだと、時間がかかったり、テストの信頼性を失うので注意。
誰が作るの？
マイクロサービスだと、これらのテストの作成は誰が担当するのか、という問題がある。複数のサービスにまたがるので、E2Eテストを作成する責任を負う単一チームがいない
一元化した品質保証(QA)チームがいるならばぴったりだけど、DevO一元化したQAチームを持つことはアンチパターン。
E2Eテストを誰が持つかはかんたんに答えを出せない。
組織に依存するところなので、組織にあったやり方で。
コストが高い
しばしばメンテナンスしなくてはならないし、実行に時間がかかる。
いくつかのマイクロサービスで構成されていると、そもそもローカル環境で実行できない。ローカルで実行するには、すべてのマイクロサービスをローカルで実行する必要がある。
E2Eテストの数は最小限にする。
商品の核となる価値部分のユーザージャーニーを考えて、その部分をE2Eテストに変換する
特殊なケースは、ユニットテストなどの下位テストに任せる。
テストツールなど
- Selenium ブラウザの自動化ツール https://selenium.dev/
- 最近までは HeadlessブラウザとしてPhantomJSが有力だったが、ヘッドレスモードが実装されたので、ユーザーが実際に使うブラウザ(Choromium, Firefox)でテストしたほうが良い
- Nightwatch.js - https://nightwatchjs.org/
ここまできたけど
多分これ上司に期待されているの、これだけじゃなさそうなんだよな。
記事の上に書かれているUIテストも含まれそう。
UIテスト
UIテストはアプリケーションのUIが正しく機能することをテストする。ユーザーの入力が正しくアクションをトリガーし、データがユーザーに表示され、UIの状態は期待通りに変わるということ。
UIテストとE2Eテストは同じものだと言われることがあるが、アプリケーションをE2Eでテストするのは、UIを介してテストを実行することであるが、その逆は当てはまらない。
つまり、UIテストはE2Eで実施する必要はない。使用する技術に応じて、バックエンドはスタブアウトして、フロントエンドのjavascriptの単体テストを記述すれば良い。
アプリケーションのレイアウトが損なわれていないことをテストするのは難しい。
これはコンピュータが「見た目の良さ」を判別し難いから。
(ただし、機械学習アルゴリズムが将来それを解決するかも)
ユーザビリティや見栄えの良さをテストするのは自動テストではなく、探索的テストやユーザービリティテストに頼るべき。
テストツール
react, vue.js, Angular
- 独自のツールとヘルパーが付属しているはず
vanilla javascript ( = つまりただのjavascript)
- jasmine - https://jasmine.github.io/
- Mocha - https://mochajs.org/index.html
伝統的なサーバサイドレンダリング
- Selenium - https://selenium.dev/
アプリケーションのレイアウト
- Galen - http://galenframework.com/
- Lineup - https://github.com/otto-de-legacy/lineup
- JLineup - https://github.com/otto-de/jlineup
まとめ
E2Eテストは、システムを用意して、UIを介してアプリケーションが動作していることを確認すること。
ただし、ユーザーのインプットに対して、
- 正しくアクションをトリガーして、データが出て、UIの状態が変わること
- UIのレイアウトが適切であること
- 期待通りの価値が提供できていること (← ここがE2Eテストの範囲)
- ユーザービリティが低下していないこと
を同時にテストするのは難しい...(手法、テストの実行時間やメンテナンスコストなどが異なる)
どれをテストするのかきちんと決めてそれぞれにあったやり方を選んでいくべき
あんまりまとまってないですが、こんなところでこの記事は落とし所にします。