E2Eテストを本格的にやったことがないのでしてみたいのだが、そもそもいくつか疑問があるのでここでぶちまけておく。
この記事ではwebサイトのE2Eテストを想定しています。他のケースはわかりません
結論
- ユーザーの挙動をシミュレートするのは、コストが大きいのに恩恵少なくない??
- ブラウザの挙動に関するロジックのテストが本義なのでは??
結論はこれです。ご意見お待ちしております。
E2Eテストに対する疑問・疑念
ユーザーの挙動をシミュレートするテストは基本的には要らないのでは? と思っている。ちゃんと単体テストできるように各モジュールを書いていたのならば、それらの単体テストだけでロジックに関しては事足りるはず。
E2E テストが不要そうなケース
たとえば以下のようなパターンは不要のはず。
- ボタンをクリックしたらこの関数が呼ばれてこういうAPIを呼んで～(略)
- フォームに情報を入力して、ログインボタンを押したらこのページに遷移
まず前者だが、関数のロジックは単体テストで保証できる。ボタンをクリックしたら関数が呼ばれるのはUIフレームワークが保証している。API に関してもモックを使えばよい。E2Eテストを持ち出すまでもない。
次に後者。これも基本的には不要のは*1。書くコスト > 恩恵。また、E2Eテストせずとも ViewModel に対する単体テストを書けばある程度カバーできる。
テストのコスト > 恩恵
上の例はどちらも、テストを書くコストに対して得られるものが少ない。しかも、上記のケースは変更も頻繁に起こりやすい箇所に対するテストなので、追従するコストも含めると完全にマイナスと言ってよい。
E2Eテストの目的は、単体テストでテストできない箇所を検証することのはずだ。しかし、上記ケースはどちらも単体テストでほぼカバーできてしまう。これでは徒にコストが嵩むだけだ。
E2Eテストが必要だと思うケース
逆に必要なのは以下のパターン。
- stopPropagation など、ブラウザのイベントハンドリング周りの挙動
- アニメーション関連(こっちはもしかしたら要らんかも)
ブラウザの状態、挙動に依存したコードはE2Eテストでなければ検証が難しい。 ブラウザの状態などに依存した箇所は単体テストでは扱いづらい。
テストしたい例としては、stopPropagation を使ってイベントの伝播を抑止できているかなどが挙げられる。複数コンポーネントがある状態で stopPropagation がちゃんと動くか調べるのは意外と難しい。
また、DOM構造に依存した箇所も問題となる可能性がある。たとえば z-index の値を間違えてしまい、クリックしたい要素に別の要素が重なるのはよく起こる。テストしても良いだろう。
*1:もちろんフォームに入力した情報がちゃんと API 呼び出しの際に使われていることをテストするのは有意義なので書いても良い
