0

モック、特にコードファーストに対してEFをテストすることに対していくつかの強力なアドバイスを見たので、テスト専用のSqlCeデータベースに対して統合テストを行い、DbContextとによって提供される作業ユニットとリポジトリのさらに下流で純粋な単体テストを使用することにしました。 DbSet。

どこに線を引くか、どこで何をテストするかがわかりません。DAL固有の統合テストがその内部をカバーしていると確信している場合、サービスレイヤーでDALをモックできることはわかっていますが、DALで何をテストしますか？EFは外部であり、すでにテストされているため、オブジェクトを保存して読み取ることができるかどうかを確認するためのポイントテストはあまりないようです。

4

4 に答える 4

1

統合テストを使用して、DALでマッピングとクエリをテストします。例：

public class Service {
   private readonly IDAL _dal;

   public Service(IDAL dal) {
       // Not null validation here
       _dal = dal;
   }

   public void DoSomething() {
       SomeData data = FindSomeData();
       // Do some logic
       _dal.Commit();
   }

   protected virtual SomeData FindSomeData() {
       return _dal.SomeData.Where(...).FirstOrDefault();
   }
}

これは非常に単純化された例で、次のことを示しています。

  • Serviceに依存しDALます。DALインターフェイスはコンストラクタインジェクションを介して渡されます。
  • Serviceロジックが正しく実行されているかどうかを確認するためにテストするパブリックDoSomethingメソッドが含まれています。ただし、この方法はDBクエリとDB永続性にも依存しています（Commit）。
  • クエリはロジックの一部ですが、そのようなクエリの実行は関心の分離であるため、独自のメソッドで処理されます。より複雑な状況では、このメソッドはServiceクラス（リポジトリ）に注入された他のクラスにある可能性があります。これらのクエリメソッドの主な基準は次のとおりです。
    • 彼らは戻らないIQueryable
    • Expression<>それらはパラメータとして受け入れません

単体テストのDoSomething方法：

  • この簡単な例では、テストクラスはクラスから派生しService、オーバーライドFindSomeDataしてテストデータを返します。インジェクションの場合、代わりにインジェクトされたクラスのフェイクを定義します。
  • また、モックを作成し、それが呼び出されたIDALことを確認できますCommit

使用する統合テスト：

  • FindSomeData実際のデータベースをクエリするためのテストを作成する必要があります
  • 一般に、の統合テストも必要ですCommitが、例にはから直接呼び出されたcommitがあるため、達成するのはより困難DoSomethingです。そのメソッドを再度テストする必要はありません。同時に、Commitメソッドは現在のコンテキストからデータベースへのすべての変更をフラッシュするだけなので、一般的なケースが多すぎます。私は通常、すべてのエンティティタイプを挿入、更新、および削除するための個別のテストを行っています。メソッドが複雑な変更を行う場合DoSomething、メソッドを2つのメソッドに分割できます。1つは実際のロジックの単体テストで処理され、もう1つはロジックで生成できるさまざまな永続性シナリオの統合テストで処理されます。
于 2012-08-30T08:52:52.023 に答える
0

Entity Frameworkはテストされていますが、DAL、特にマッピングはテストされていません。少なくとも私のマッピングが正しいこと、さらにはデータベースに対してすべてのCRUD操作を正常に実行できることを示すために、統合テストを行うことを好みます。

于 2012-08-30T06:49:24.820 に答える
0

私たちが通常DBに関してテストするのは、複雑なオブジェクトグラフを適切に挿入、更新、削除できるかどうかです。基本的に、より複雑なマッピングをテストします。
私の意見では、3つのプリミティブ値のプロパティを持つオブジェクトを挿入できるかどうかをテストする意味はあまりありません。そうすると、オブジェクトの終わりが表示されなくなるためです。
私たちは楽観的であり（単純なものでもうまくいく）、より複雑な関連付けをテストし、マッピングでエラーが発生した場合（たとえば、削除する必要があるが削除されないオブジェクト）、追加のテストを作成します。そのために。
通常、ビジネスの観点からすべてを完全にテストすることは賢明ではありません。最初に高リスク/高損傷のものに焦点を合わせてから、それがもはや価値がないと思うまで、重大度のはしごを下っていく必要があります。

于 2012-08-30T10:59:49.017 に答える
0

1）マッピングをテストする一連の統合テストを用意する

2）DALを非常に軽量にしますが、次のようなクエリを作成するのに十分な能力を備えています。

public interface IDb
{
    IQueryable<T>Query<T>();
    ... (save, delete, get-by-id methods)...
}

3）DALに対するクエリの構築の背後にあるロジックをカプセル化するオブジェクトを記述します

public class MuppetSearch
{
    public MuppetColor? Color { get; set;}
    public string Name{ get; set; }
    public IQueryable<Muppet> ConstructQuery(IDb db)
    {
        var query = db.Query<Muppet>();
        if(Color.HasValue)
        {
            query = query.Where(m=>m.Value == Color.Value);
        }
        if(!String.IsNullOrEmpty(Name))
        {
            query = query.Where(m=>m.Name.Contains(Name));
        }
        return query;
    }
}

4）それらをテストし、必要なすべてのデータをモックするのはかなり簡単なはずです

5）サービスでは、検索クラスを使用してクエリを構築します

于 2012-08-30T14:01:37.947 に答える