Remix.runのKent C.Dodds氏や、VercelのGuillermo Rauch氏などの著名なソフトウェアエンジニアは、統合テストがE2Eテストよりも低コストで、単体テストよりもカバー範囲が広いことを理由に、もっと統合テストを重視するように提唱しています。
「静的テスト、単体テスト、統合テスト、E2Eテストのバランスはチームが何を重視するかによって変化します。このバランスは、厳密なルールとして捉えるべきものではないでしょう。
あくまで一般論です。使用できるツールでアプリをテストするのがどれだけ簡単か、難しいかによって、実際に異なるのです。 一般的な考え方は、静的テストと統合テストによって、かけたコストに対してユーザに“素晴らしい”価値を保証します。そして単体テストとE2Eテストによって、“良い”価値が得ることができのです。なので全て利用していきましょう」
統合テストの大きな価値の一つは、E2Eテストと同じようにユーザーのふるまいをテストできることにあります。 ユーザーがコンポーネントを単体で使用することはほとんどなく、ほとんどのWebアプリは、異なるコンポーネント間の相互作用として実行されます。
このため、統合テストは、特定のロジックの入力と出力をテストするだけの単体テストと比べて、テスト結果の信頼性が高くなると思います。
なので、最初に書くべきなのは統合テストだと捉えています。 この考え方は、ほとんどの人は直感に反したり、異なる意見を持っているかもしれません。
開発サイクルの中で不具合を発見するのが遅ければ遅いほど、その修正にかかる費用は高くなると教えられてきました。統合テストなどの「大きなタスク」に着手する前に、すべての細部を完璧にしようとします。
先に単体テストを書いていては必要なビジネスロジックを柔軟に変更しながら開発を進めることができません。
確かに関数/メソッドレベルのユニットテストより、それらを呼び出すエンドポイント的な部分のテストから書き始めることが多い。
例えば、コントローラやユースケースの実装＆テストから始めて実際にテストを動かしながら実装を進める方がやりやすい。