ユニットテストケースを書くときになぜモックオブジェクトを書くのですか？

現在、プロジェクトで単体テストケースを作成しています。データベースメソッドの実装が存在し、正常に動作しています。この場合、モックオブジェクトを作成する必要があるのはなぜですか？具体的な理由はありますか？DAO実装を直接テストできないのはなぜですか？

データベースの呼び出しを模倣してはいけません。目的を達成できないからです。あなたがモックすべきなのは、たとえば、サービス層からのDAOの呼び出しなどです。モッキングを使用すると、メソッドを個別にテストできます。

次のようなアーキテクチャのレストランシミュレーションがあるとします。

Cook <=> Server <=> Customer

各レイヤーを個別にテストしたい。ここServerがサービス層であり、CookDAOと考えることができます。これServerは、テスト中にモックしたいものCustomerであり、Cookテスト中にモックしたいものですServer。Cookユニットテストは、しかし、ハンバーガーをゴムタイヤを注文しなかった場合、実装は、ハンバーガーを返していることを確認すべきです。

データベースと一緒にbusinesslogicをテストしても問題ありません。ただし、これらのテストは、nunit、junit、phpunitを使用して実行する場合でも、統合テストと呼ばれます。

単体テストは、個別のテスト（つまり、データベースのないbuisinesslogic）が重要な特殊化テストです。モック/偽物/迷惑メールは、この分離を強制するために使用されます。

単に：データベースのコンテンツではなく、実際のDAOをテストします。

DAO PersonクラスにメソッドgetByName（）があるとします。テストを作成して、Person.getByName（ "John Smith"）を呼び出します。誰かがジョンのレコードをデータベースから削除したため、テストが失敗したとします。これで、すべてのCIソフトウェアとスーパーバイザ/レビュアーは、ソフトウェアに欠陥があると主張できますが、実際には問題はありません。DBをモックする場合、正しいテーブルから正しい行が与えられれば、DAOが機能することを証明できます。

データベース自体を本当にテストしたい場合、つまり、特定のDAOメソッドを実行してデータを特定の状態にする場合は、それも可能です。さらに、データベースが完全な整合性を提供することを期待できない奇抜なデータモデル（EAV、ネストされたツリーセット）で本当に役立ちます。あなたの人生を楽にするためにDBUnitを見てください。

別の理由は、実際にデータベースコマンドを実行する実行時間を回避するためです。それほど多くはないように思えるかもしれませんが、接続の設定と切断のオーバーヘッドが最終的には加算され、モックオブジェクトを使用する場合と比較して、テストスイートを実行する全体の時間が大幅に増加する可能性があります。

テストするクラスを分離するため。または、テストが失敗した場合、テストしているクラスまたはその依存関係の1つに問題があることをどのようにして知ることができますか。