第2回：毎日の自動テストを無理なく続けるためのキーワード

前回のおさらい

前回の記事では、E2Eテストの自動化において最初に気をつけるべき目的の設定と毎日テストを実行することの重要性、そして導入のステップについてお伝えしました。第2回となる今回は、実際に毎日の自動テストの運用を始めてから遭遇しがちな具体的な課題と対策についてお話ししたいと思います。

運用時にありがちな課題

自動テストの運用で、必ずと言っていいほど出てくるのが以下のような課題です。

失敗したテストの解析に時間がかかる

自動テストは実行したら当然結果を確認し、失敗したテストがあればアプリケーションの不具合によるものなのか、テストケースに誤りがあるのか、または環境要因かを切り分けてそれぞれ対処する必要があります。毎日の作業なので、ここに時間がかかり過ぎると「自動テスト＝つらいもの」という認識が生まれ、自動テストをさらに有効活用していこうというモチベーションが失われてしまいます。

Flakyなテスト（結果が一定にならず、成功したり失敗したりするテスト）がある

実行の内容やどのようなアサーション（結果の確認）を入れているかにもよりますが、「同じ手順で実行しているはずなのになぜか時々失敗してしまうテスト」というのは非常によく発生します。前述の「失敗したテストの解析」をひときわ難しくするのがこのFlakyなテストです。原因はテスト対象のアプリケーションのレスポンスタイムのちょっとしたずれ、ブラウザのバージョンアップなど様々で、筆者が経験した中では「テスト用のPCでウィルスチェックが走って動作が重くなったため」というものもありました。

実行時間が長い

E2EテストはUnitテストに比べてどうしても実行時間が長くなりがちです。そのため前回記事の冒頭でも「テストのピラミッド」として紹介したようにそもそも数を多く作りすぎないことも重要なのですが、必要なテストだけでも数時間となってしまうこともあります。すると前日の開発分のテストが翌日朝に終わらないという状況になり、フィードバックが遅れることで自動テストへの対応が遅くなる→メンテナンスしづらくなり陳腐化するというリスクがあります。

これらの問題をすべて解決する銀の弾丸は存在しませんが、意識しておくべきかどうかで大きく結果が変わってくるのが「テストケースの独立性」というキーワードです。

独立性とは？

「良い単体テストの条件」として有名な「F.I.R.S.Tの原則」というものがあります。それぞれFast(迅速)、Isolated/Independent(独立)、Repeatable(繰り返し可能)、Self-validating(自己検証可能)、Timely(タイムリー)の頭文字を取っています。単体テストとE2Eテストでは前提条件が大きく異なりますが、E2EテストでもIndependent(独立)とRepeatable(繰り返し可能)の原則はとても重要です。テストが独立していて繰り返し可能であるということは、つまり日次実行のときと同じ順序で実行する必要がなく1ケースだけで実行可能であり、何度実行しても同じ結果になるということです。

これが達成されていると、以下のようなメリットがあります。

• 失敗したときに素早く単独で再実行できる：テストケースが独立していると、失敗したテストだけを再実行することが容易になります。これにより、毎日の解析と修正が迅速に行えるようになります。
• Flakinessにも対応しやすい：上と同じ理由で手軽に再実行できるためどれくらいFlakyであるかを簡単にチェックできるというメリットが1つあります。加えて、そもそもテストが繰り返し実行可能でないこと自体がFlakinessを生んでいる場合も多い（前回のテストで生成されたデータを正しく削除していないと次回のテストが失敗する等）ため、対処すべきFlakinessが減るというメリットもあります。
• 実行時間を短くできる：独立性が保たれているテストケースは、（多くの場合）並列実行が可能になります。その結果、テスト全体の実行時間が短縮され、開発者に素早いフィードバックを提供できます。

いかがでしょうか。ありがちな課題に応えられているように見えますね。