私のオフィスでは、ファイルシステム（DBなど）との対話を主な責務とするクラスの統合テストに加えて、単体テストの必要性について論争があります。
テストされたオブジェクトは他のオブジェクトとまったく相互作用しないため、私たちが行っている統合テストはほとんど単体テストです。テスト統合と呼ぶ唯一の理由は、実際のファイルシステムがテストで使用されることです。そして、テストされたクラスにファイルシステムレイヤーコンポーネントを使用させ、それをテストでモックし（単体テストと呼びます）、実際のファイルシステムの結果ではなく、このコンポーネントとの相互作用をチェックすることが提案されています。この変更の必要性は、私たちが議論することです。
私たちの見解の1つは、次の理由から、単体テストが常に必要であるということです。
- 単体テストを書くと、コードがはるかに良くなります
- 単体テストがあれば、実際のファイルシステムやファイルの副作用を気にする必要がなく、間違った場所に表示されます
- 開発者は、テストされたクラスにファイルシステムのモックを使用させ、そのモックに適切な期待値を設定することで、結果を完全にテストできます。
- 単体テストでホワイトボックステストを行うため、モックの期待値をテストされたクラスの特定の内部アルゴリズムに結び付けることは問題ありません。
したがって、単体テストは、そのようなテストされたクラスに対して常に作成する必要があります。また、ファイルシステムレイヤーコンポーネントは、テストの目的でそのクラスによって常に使用される必要があります。
もう1つの観点は、ファイルシステムの相互作用に専念するクラスの特定のエッジケースには単体テストは必要ないということです。理由は次のとおりです。
- 実際のファイルシステム（またはその完全なエミュレーション）の代わりに単純なモックを使用するだけでは、テストされたクラスが機能することを適切に検証することはできません。ファイルシステムは非常に複雑なコンポーネントであり、次のようなものです。
- テストされたクラスは、成功する結果を達成するために多くの異なる方法で機能することができます。モックの期待値は、考えられるシナリオの1つから2つだけをカバーしているため、単体テストでは、期待されるものとは異なる、適切なアルゴリズムを適切に実装するクラスの失敗が誤って示されます。
- テストされたクラスは、モックによって成功したシナリオとして検出された方法で機能しますが、クラスはまだ正しい結果を生成しません。これは、実際のファイルシステムでは非常に複雑な理由が原因である可能性があります。これらすべての理由は、モックだけでカバーすることは不可能です。
- モックと期待値を使用した単体テストは、テストされたクラスの内部アルゴリズムに非常に関連しているため、非常に脆弱です。また、アルゴリズムを正しく変更しても、テストは誤って失敗します。
- 統合テストは、クラスに1〜2個のパブリックメソッドがあり、依存関係のみがファイルシステムである場合の単体テストの適切かつ完全な代替手段です。統合テストは、この場合の単体テストと同じ利点を提供します-明確な依存関係、より読みやすいコードなど。
したがって、この場合、ファイルシステムのモックを使用した単体テストは必要ありません。これは壊れやすく、この特定のクラスの場合には正確ではありません。
つまり、要約すると、問題は次のとおり
です。ファイルシステム（DBなど）を操作する主な責任を持つ複雑なクラスがないというエッジケースに対して、統合テストは十分に十分ですか？
このクラスの統合テストと単体テストの唯一の違いは、単体テストではファイルシステムのモックが使用され（クラスは完全に分離されます）、統合テストでは実際のファイルシステムが使用されることです。
古典的な本、あるいは有名な業界関係者の記事やプレゼンテーションへの参照を追加していただければ幸いです。そうすれば、結果として得られる結論を裏付ける非常に強力な基盤を築くことができます。