本記事はAdvent Calendar 2024、「テスト自動化あるある言いたい by T-DASH」シリーズ15日目の記事です。
今回は不安定なE2E（End-to-End）テストについてデメリットや対応策の話させていただきます。
フレーキーなテスト
E2Eテストは、アプリケーションの全体的な機能やユーザーエクスペリエンスを検証する強力な手法ですが、テストが不安定になりやすいです。
不安定なテストが多くなると下記のような問題があります。
- テスト結果の信頼性が低下する
E2Eテストが頻繁に失敗していると、「失敗＝問題ではない」という心理がチームに浸透してしまいます。その結果、実際に重大な不具合が発生しても見過ごされる可能性があります。
「あ、このテストはいつも失敗してるから無視でいいよ」といった状況が日常化してしまいます。
- デバッグコストが増加する
テストが失敗するたびに調査が必要になると、開発チームの負担が増加します。E2Eテストは全体の機能をテストする分調査対象も大きく、原因がテストコードの問題なのか、本番コードのバグなのかが曖昧だと、根本的な解決には至らず、同じ問題が何度も発生します。
- 開発のスピードと品質に悪影響
テスト失敗が常態化すると、E2Eテスト自体の目的である「プロダクト品質の担保」が揺らぎます。結果的に、チーム全体の信頼と開発スピードが低下します。
対応策
それではフレーキーなテストの対応策を紹介します。
- E2Eテストを必要以上に多用しない
上記でも記述した通り E2Eテストはその性質上不安定になりやすいです。単体テストや統合テストと組み合わせることで、効率よくプロダクトの品質を担保しましょう。単体テスト、統合テストでカバーできるのであればE2Eテストは不要かと思います。
同値分割法や強化位置分析を使ったテストなど網羅的なテストなど単体テストでカバーできることが多いかと思います.
- 失敗したテストをそのままにしない
失敗したテストがあれば、その原因を必ず特定しましょう。
原因は大きく以下の3つに分けられます：
• テストコードの不具合
• アプリケーションコードのバグ
• 外部要因（ネットワークや環境の問題）
それぞれに適切な対応を取り、再発防止策を検討することが重要です。
テストがフレーキーになる原因
テストコードがフレーキー（Flaky）になりやすい要因はいくつかあります。以下にフレーキーになりやすい要因とその例を挙げます。
- 固定秒数の待機処理
例えばテスト中ページ遷移などを待つ時にsetTimeoutやThread.sleep、waitForのように固定の秒数だけ待機するコードを使うと、想定より処理に時間がかかった場合に失敗しますし、長く取った場合は時間が多くかかってしまいます。
例:
// 不安定な例
await page.waitForTimeout(2000); // DOMがレンダリングされるのを2秒待つ
await page.click('#submit-button');
解決策: 固定秒数待機を避け、特定の条件（要素の可視化やAPIレスポンスの完了）を待つようにする。
await page.waitForSelector('#submit-button', { state: 'visible' });
await page.click('#submit-button');
- テストデータや環境への依存
テストが動的なデータや特定の環境（ネットワーク、データベースの状態など）に依存していると、不安定になります。
解決策
- E2Eテストで使うものは専用のデータを準備
- モックデータを使用: APIレスポンスやデータベースのクエリをモック化する
- 隔離された環境を作る: Dockerや専用のテストデータベースを使用する
まとめ
今回は不安定なE2Eテストのデメリットや対応策など紹介させていただきました。
ここで紹介下以外にも色々なアンチパターンがあると思います。ご参考になれば幸いです。