10

私は EF を初めて使用します。SQL Server データベースで EF を作成する最良の方法を知りたいです。その後、CRUD 操作をテストしたいと思います。EF は TDD の方法で実装されていますか?これらのリポジトリ パターン、モック コンテキスト、偽のパターンなどに混乱しています。

EF での CRUD 操作では、どのようなものがテストされるのでしょうか? ( DbContext, SaveChanges()... テストする必要がありますか?)

Entity Framework ベースのコンポーネントで単体テストを行う方法はありますか? (私は Visual Studio 2012、ASP.NET MVC4 でこれらすべてをチェックしています)

4

4 に答える 4

18

2層ソリューションがあるとしましょう

MyApp.Web

MyApp.Data

データレイヤーには、次のようなものがあります。

public class ProductsRepository : IProductsRepository
{
     public List<Product> GetAll()
     {
        //EF stuff 
        return _dbcontext.Products;
     }
} 

IProductsRepository の場所

public interface IProductsRepository
{
   List<Product> GetAll();
}

MyApp.Web では、これを行う傾向があります。

public class ProductsController : Controller
{
    private readonly IProductsRepository _productsRepository;
    public ProductsController(IProductsRepository productsRepository)
    {
        _productsRepository = productsRepository;
    }

    public ActionResult Index(int page=1)
    {
        var allProducts = _productsRepository.GetAll();

        return View(allProducts)
    }
}

実行時にProductsRepositoryをコンストラクターに入れるのは誰ですか? これには、 Ninjectフレームワークのような依存性注入が使用されます。しかし、なぜ?これにより、 ProductsRepositoryを偽造し、このようにすることができるためです。

public class FakeProductsRepository : IProductsRepository
{
     public List<Product> GetAll()
     {
        return new List<Product> 
           { 
              new Product { Name = "PASTE" }
              new Product { Name = "BRUSH" } 
           }, 
     }
} 

そして、このようにコントローラーをユニットテストします

 [TestMethod]
 public void IndexGetsAllProducts()
 {
        //Arrange 
        var fakeProductRepo = new FakeProductsRepository();
        var productsController = new ProductsController(fakeProductRepo);

        //Act
        var result = productsController.Index(1) as ViewResult;

        //Assert
        var model = result.Model as List<Product>;
        Assert.AreEqual(2, model.Count);
 }

基本的に、単体テストが高速でデータベースに依存しないように、データベースを偽造しています。偽装のためにMoqのようなモッキングフレームワークを使用することがありますが、これは基本的に同じことを行います。

ProductsRepositoryをテストする場合は、外部ソースに依存するため、単体テストとは呼ばれなくなりました。それらをテストするには、本質的にEntityframeworkをテストしています。

単体テストと組み合わせて、人々は Specflow のようなフレームワークを使用して統合テストを行います。基本的に、実際のProductsRepositoryを使用してProductscontrollerをインスタンス化し、返される結果を確認できます。

于 2013-10-16T23:07:01.330 に答える
5

EF 機能をテストするには、既知のデータに対して統合テストを作成することをお勧めします。一般的なアプローチは、選択ベースの機能のテストの前提条件として、テストの一部としてデータを構築することです。

元:

  1. 既知のデータを挿入

  2. 既知のデータに対して選択機能を実行する

  3. 結果をアサートする

上記の手順では、クエリと EF バインディング/モデルの両方をテストします。

EF から返されたデータに作用するビジネス ロジックは、モックによって EF ロジックを抽象化する必要があります。これにより、統合ポイント/データの依存関係を気にすることなく、ロジックのみのテストに焦点を当てた単体テストを作成できます。

于 2013-10-10T04:35:22.137 に答える
5

リポジトリと作業単位のパターンは、アプリケーションのデータ アクセス層とビジネス ロジック層の間に抽象化層を作成することを目的としています。これらのパターンを実装すると、アプリケーションをデータ ストアの変更から隔離し、自動化された単体テストやテスト駆動開発 (TDD) を促進できます。

例の説明については、ここに移動してください。

于 2013-10-15T13:46:47.410 に答える
2

代わりに、インメモリ データベースを使用して EF モデルをテストすることもできます。これは、単体テストのデータベースとして Effort を使用する例です。

于 2013-10-15T12:09:33.903 に答える