2

A は、典型的なシナリオのデータ アクセス レイヤー (DAL) を備えたアプリケーションを持っています。

  • Entity Framework (EF) で作成されたデータ コンテキスト。
  • アプリケーション全体の一般的な DTO として使用される EF によって生成されたエンティティを使用します。
  • DAL には、基本的な CRUD 操作を実装する RepositoryBase 抽象クラスを拡張するさまざまなリポジトリが含まれています。特定のリポジトリには、エンティティ タイプに固有のメソッドしかありません。論理的に削除できるエンティティのリポジトリは、代わりに、それ自体が RepositoryBase を拡張する SoftDeleteRepositoryBase を拡張します。

コンテキストを示すために、いくつかのクラス/インターフェースを次に示します。

汎用リポジトリ インターフェイス:

public interface IRepository<T> : IDisposable where T : class
{
    void Add(T entity);
    void Update(T entity);
    void Obliterate(T entity);
    void Obliterate(Expression<Func<T, bool>> where);
    T GetById(long id);
    T GetById(string id);
    IQueryable<T> GetAll();
    IQueryable<T> GetMany(Expression<Func<T, bool>> where);
    T GetSingle(Expression<Func<T, bool>> where);
    void SaveChanges();
}

リポジトリベース:

public abstract class RepositoryBase<T> : IRepository<T> where T : class
{
    ...
}

Foo エンティティのリポジトリ:

public class FooRepository : RepositoryBase<File>, IFooRepository
{
    // Specific methods here
    ...
}

リポジトリをテストするにはどうすればよいですか? 現在、リポジトリごとにテスト クラスがあり、ほとんどが RepositoryBase のジェネリック メソッドをテストしているため、すべてのテスト メソッドが非常に似ています。特定のメソッドのテストが必要であることは明らかですが、グローバルなジェネリック メソッドについては、異なるエンティティごとにテストし続ける必要がありますか? たとえば、挿入が Foo エンティティで機能する場合、他のエンティティでも機能すると想定するのが賢明かどうかはわかりません。ただし、それぞれのテストには、テストの作成と保守に関してオーバーヘッドが追加されます。これに関するベストプラクティスをお勧めできますか?

（ちなみに、これらは統合テストです）

ありがとう

4

1 に答える 1