AI時代にE2Eテストが何故大事なのか？
文章目录
Xで「AI時代はE2Eテストの重要性が上がる」という話がニュースまとめになっていて、私もこの議論に加わっているので、ここでもう少し深掘りした自分の考えをまとめておきたい。
結論から言うと、この方針に大きく賛成でAIによって実装コストが急速に下がる一方で、相対的に大きくなっているのが検証コストであり、それを自動化しない限り我々は一生ボトルネックに悩まされるからだ。
ユニットテストだけでは品質保証として弱い
今のコーディングエージェントは、ユニットテストを与えれば、それを通す実装をかなり高い確率で生成できる。
もちろん、だからといってユニットテストが不要になるわけではない。
高速に実行でき、CIでも常時回せるため、既存実装を壊していないことを確認するリグレッション検知のQuality Gateとしては依然として重要だと思う。
ただし、「ユニットテストが通った」と「ユーザーが期待する機能が正しく動いている」は同義ではない。
最終的な振る舞いを保証するうえで重要になるのは、E2E Testや、ある程度大きな境界をまたぐIntegration Testだ。
API、DB、外部サービス、UIなどを含め、個々の部品ではなくシステム全体として期待する振る舞いになっているかを確認する必要がある。
ボトルネックは実装から検証に移っている
以前は、実装そのものに大きな時間がかかっていた。今はそのかなりの部分をコーディングエージェントに委譲できる。
そうなると、実際に時間を使うのは、
-
期待通りに動いているかの確認
-
リグレッションの確認
-
失敗原因の分析
-
デバッグ
-
修正後の再検証
といった実装後の工程になる。
実装が数分で終わっても、そのあと人間がブラウザを開いて30分間動作確認しているのであれば、開発が速くなったのではなく、単にボトルネックが別の場所へ移っただけだ。
だからAI駆動開発を進めるのであれば、コード生成の次に自動化すべきなのは検証だと思っている。
「E2Eは壊れやすい」という問題
E2E Testには昔から、
「Flakyになりやすい」 「メンテナンスコストが高い」
という問題がある。
これは従来かなり妥当な指摘だった。ただ、AIエージェントがテストコードそのものを修正できるようになると、人間が負担するメンテナンスコストは大きく下がる。
DOM変更への追従、Selectorの修正、Fixtureの更新、失敗原因の分析、テストコードの修正といった作業までエージェントに任せられる。Computer Useを組み合わせれば、実際のブラウザ操作を含めた検証まで自動化できる。
もちろんFlaky Testそのものがなくなるわけではない。
ただ、「E2Eは人間が維持するにはコストが高すぎる」という、これまで大きかった制約はかなり弱くなっていると思う。
全テストを毎回実行する必要もない
もう一つの問題は実行時間だ。
E2E TestやIntegration Testが数百と増えれば、PRごとにFull Suiteを実行するのは現実的ではない。
ただし、ここも「毎回すべてのテストを実行する」という前提を外せばいい。変更されたコード、依存関係、Coverage、過去の失敗履歴などを入力として、「今回の変更に対して、どのTest Suiteを実行すべきか」を軽量なClassifierやLLM Judgeに選択させる。
それこそJevみたいなものが妥当ではないか？
例えば、
PR ↓ Change Analysis ↓ Test Selection ↓ Relevant Integration / E2E Tests ↓ Quality Gate
というパイプラインにする。
自分もローカルでは、変更内容に応じて必要なE2EやIntegration Testだけを選択して実行する形を使うことが多い。
CIに持っていくのであれば、
Mandatory Smoke Tests ＋ Change-aware Test Selection
くらいの構成が現実的だと思う。
もちろんTest SelectionにもFalse Negativeはある。なので結局フレーキーなことに変わりはない。なので私はリリースゲートにこれを置くことにはまだ懐疑的ではある。
まとめ
最後にまとめると
-
AIで実装コストは大きく下がった
-
次のボトルネックは検証
-
ユニットテストはリグレッション検知として重要
-
ただし品質保証にはE2E / Integration Testが必要
-
E2Eの維持コストもAIで下げられる
-
全件実行ではなく、変更に応じたTest Selectionも有効
という感じ。今後も何がベストな方法なのかを模索していきたい。
