Web アプリケーションにおける E2E テストは、最もユーザーに近い視点で広範囲をまとめてカバー出来るが、実装・実行のコストが高く運用の難易度が高いということで知られている。
現職で担当しているプロダクトでも、Playwright を使用した E2E テストを立ち上げて運用しているが、今日はその E2E テストが不可解な落ち方をするようになって調べるのにかなり時間を使っていた。
結果としては、裏側で呼び出されている複数の API の完了タイミングにテスト結果が左右されるという、いわゆるレースコンディションのような問題だった。
こういうパターンのデバッグは本当に難しい。まずローカルじゃ再現できないことが多いし、ヘッドレスブラウザかヘッドフルブラウザかでまた話も変わったりする。
ある程度慣れてくると、トラブルシューティングのコツも掴めてくるのだが、その経験則をチームに共有するのがまた難しく、属人化を加速させてしまう。
みんなでE2Eテストを運用するようにすればなんとかなるとは思いつつも、メンバーが入れ替わるたびにそういった労力を払うのかと思うと、やはりアプリケーションの設計・実装の段階から E2E テストが安定しやすい作り方というのを考えたい。
例えば今回の場合は、互いに独立したAPI3種が、並列でなく直列で実行されているところが根本的な問題だった。これを避けるために、依存関係のない複数のAPIはなるべく並列に動作するように普段から設計を心がけるなどが考えられる。
そんな感じに、E2Eテストの存在がアプリケーションの設計・実装をよくするような世界を作っていきたい。