背景
フロントエンドのテスト設計を調べる中で、テスティングトロフィーという考え方を知りました。
ユーザーに近いテストを重視するという思想に共感し、「できるだけ統合テストで保証する構成」に寄せました。
結果として、単体テストがなく、統合テストのみになっていきました。
起きた問題
- テストケースが増えるにつれて、実行時間が徐々に長くなりました
- 単体で実行すると成功するが、並列実行時に不安定になるケースが出てきました
原因
単体テストで十分に保証できるロジックまで、統合テストでカバーしようとしていたことが原因でした。
また、「ユーザーに近いテストが良い」という方針をそのまま適用し、テストの粒度を分けて考えられていませんでした。
今どうしているか
単体テスト・統合テスト・E2Eテストのバランスを見直し、単体テストを増やす形にしました。
学び
ユーザー目線を重視するあまり、「ユーザーが実際使用するようなイメージでテストで書くべき」と極端に解釈してしまったことが失敗の要因でした。
テスティングトロフィーの考え方は大切にしつつも、単体テスト、統合テスト、E2Eテストでそれぞれバランスをとることが重要だと学びました。
今後は、下の階層で保証できるものはできるだけ下の階層で保証するようにし、効率的で壊れにくいテスト設計を意識していきたいです。