ユニットテストのためのデータベース依存関係を避けるために

Question

私はデータベースアクセスを必要とするメソッドを持つ多くのオブジェクトを持っています。私たちは単体テストを目指していますが、可能であればモックオブジェクトの使用を避けたいと考えています。私は、DBアクセスを必要としないように、以下に示すValidateメソッドをリファクタリングする方法があるかどうか疑問に思っています。実際のアプリケーションでは、通常はかなり進んでいますが、この単純化された例で十分であると思います。

モックオブジェクトは必要な場合に使用する方法を学びますが、オーバーヘッドのように思えるので、代替案を探しています。

public class Person 
    { 
     public string Name; 

     public string Validate() 
     { 
      if (PersonDA.NameExists(Name)) 
      { 
       return "Name Already Used"; 
      } 

     } 
    } 

Answer 1

私はちょうどモックオブジェクトルートに行きます。はるかに柔軟性があり、あなたの実際のオブジェクトにテストコードを置く道を踏み出そうとしているように聞こえますか？

もちろん、検証コードをboolean isValid（Person）のメソッドでPersonValidatorオブジェクトに抽出します。テストコードでは、テストケースに基づいてtrueまたはfalseを返すモックバリデーターを使用します。

Answer 2

単体テストに使用するデータベースを設定してください。 すべてのデータアクセスにモックアップを使用すると、実際にはあまりテストしないでしょうか？ :)

Answer 3

dbunitを見てください。これは特に、小さなテストデータベースを設定するように設定されているため、単体テスト時に実際のオブジェクトをモックデータベース上で使用できます。それを使ったテストは、モックオブジェクトを開発するよりはるかに簡単で、データアクセスコードを変更するよりはるかに安全です。

Answer 4

Personクラスは、データベースアクセスコードに隠れて静的な依存関係があるため、単体テストが難しいです。 Personと、状態を検証するために必要な情報を提供するいくつかの新しいタイプのオブジェクトとの間に動的なコラボレーションを導入することによって、この結合を破ることができます。 Personの単体テストでは、Personオブジェクトの "スタブ"実装をコラボレーターに渡すことで、データベースにヒットせずに有効か無効かをテストできます。

データベースに当てはまる実際の実装を個別のテストでテストできます。これらのテストは遅くなりますが、アクセッサメソッドの複雑なロジックがなくてもデータベースクエリへの直接的な変換が行われるため、テストの数は少なくなります。

あなたが望むのであれば "モックオブジェクトを使用する"ことができますが、現在の設計ではコマンドを期待するのではなくクエリをスタブする必要があるため、モックオブジェクトフレームワークはあまりにも複雑なツールです。手書きのスタブは、テストの失敗を診断しやすくします。

Answer 5

なぜモックを避けようとしていますか？単体テストを実践し、データアクセスコードを持っている場合は、モック/スタブ/インジェクト方法に快適になるのが最も簡単です。

モックフレームワークを持ちたくない場合は、必要に応じて単純なスタブをコード化することができます。

データアクセスコードをインターフェイスの背後に置くと、データベースが不要になります。テスト中に依存関係注入を使用して模擬コードまたはスタブデータアクセスコードを挿入することを検討してください。