E2Eテストについて考えてみた

こんにちは。MMMサーバサイドエンジニアの柳沼です。お世話になっております。
入社して一ヶ月ほど経ちました。

MMMでは、隔週で「ソフトウェアテスト指針分科会」という勉強会を行っています。
テストコードを書かないプロジェクトはほとんど皆無なため、
どのようなテストを書くか、テストのあり方、メンテナビリティ、
パフォーマンスなどについて、メンバーで話し合っています。

次回のテーマが「E2Eテストについて」なので、
この場を借りて私の考えをまとめてみようと思います。

書く内容は、「E2Eテストで何をテストすべきか」です。
フレームワークの使い方や、テストコードの書き方については書きません。

なんのためにテストを書くのか？

そもそもテストはなんのために書かれるのでしょうか？
リリースのたびに同じテストをするのは面倒だし、
自動化したいから。だとするならば、
そもそもなんのためにテストをするのでしょうか？

テストは、バグを検知するために行われます。
では、なぜバグを検知したいのでしょうか？

それは、運用が始まってからバグが発生すると、
修正コストがかかる からです。

バグの修正のためにサービスを停止させる必要があるかもしれないし、
バグを修正している間は取り掛かっている仕事がストップしてしまいます。
瑕疵(無償対応)の場合は、人月としてのコストもかかってしまいます。

つまり、テストをしないと、あとで無駄なコストが発生する可能性が高まります。
これを潰すためにテストを行います。

E2Eテストとは

E2Eテストとは、End To End テストの意味です。
一般的には、フレームワークを利用して実際の
ブラウザでの動きをシミュレーションするようなテスト、
という意味で使われることが多いと思います。
ユーザが実際にどう操作するか、という視点でテストが行われます。

E2Eテストではなにをテストすべきか

そもそもユニットテストだけではなぜ足りないのか？

まず前提として、 この世にバグのないプログラムは存在しません。

人間が作っているのだから当たり前、と言う以前に、
バグを完璧に定義することは人間にはできないからです。
バグかどうかを判断するのは人間です。

プログラムは、書かれた通りに動くことしかできません。
それは、テストコードにおいても同様です。
つまり、
ユニットテストは、
その部品が正しく動くことを担保する以上のことはできません。
そして、バグがあるかどうかは、部品が正しく動くこととは別の問題です。

じゃあ全部E2Eテストすればいいんじゃないの？

前述の通り、ユニットテストは部品が正しく動くことを
保証することしかできません。

じゃあその部品のユニットテストは不要なのか？と言うと、違います。
必要です。

なぜかと言うと、きちんとテストされた部品ならば、
再利用がしやすい からです。

部品はひとつひとつの機能をなるべく小さくて、
再利用性に長けている必要があります。

その時、十分にテストされた部品は、
プログラマが安心して利用することができます。

また、E2Eテストはユニットテストに比べて、
実行時の時間的コストが高いことが多いです。
そのため、全ての機能にE2Eテストを実装すると、
実行するだけで時間を取られて消耗します。

E2Eでなにをテストすべきか

私はE2Eテストを書く時、
このテストが失敗したらだいぶ(システム的にも、ビジネス的にも)つらい
というものに絞って書くようにしています。
テストに時間がかかることは嬉しくないので、最低限に絞ることは意識しています。

例えば、表示の崩れなどの、
「仕様と違っていたら直す必要があるけど、まあ早急につらくはない」
ような問題に、E2Eテストを書くのは時間の無駄です。
(テストを書く時間・レビューする時間・実行する時間含め)

しかし、例えば弊社コーポレートサイトで言えば、
「お問い合わせ画面から問い合わせのメールが飛ぶこと」
のような、
「もしここがコケたらつらい、このコーポレートサイトなんのためにあるのか？」
みたいになってしまう部分は、時間的コストをかけてでも
E2Eテストを行う必要があると思います。

まとめ

E2Eテストを実装する際は、
「このシステムはなんのためにあるのか？」を考えると、
実装すべき箇所が見えてくるかと思います。
本エントリが、開発者の皆様のご参考になれば幸いです。

デロイト トーマツ ウェブサービス株式会社(DWS)

デロイト トーマツ ウェブサービス株式会社はアマゾン ウェブ サービス（AWS）に 専門性や実績を認定された公式パートナーです。