10

Jestem bardzo nowa w EF, chcę wiedzieć, jaki jest najlepszy sposób tworzenia EF z bazą danych SQL Server. Potem chcę przetestować operacje CRUD. Czy EF jest implementowany w sposób TDD i jestem zdezorientowany tymi wzorcami repozytoriów, fałszywym kontekstem, fałszywym wzorcem itp.Jednostka testowania i struktura jednostek

Operacje CRUD w EF, jakie wszystkie rzeczy byłyby testowane? (DbContext, SaveChanges() ... trzeba przetestować?)

Jakie są pomysły na testowanie jednostkowe z komponentami opartymi na Entity Framework? (Sprawdzam wszystkie te w Visual Studio 2012, ASP.NET MVC4)

+2

Tylko dla FYI: Są one nazywane ogólnie testami integracyjnymi. Jeśli były to testy jednostkowe, to uderzałbyś "Run Tests .." co 30 sekund (tak jak powinieneś być w TDD), a objazd do bazy danych dla każdego testu sprawiłby, że twoje testy przebiegałyby przez minuty/godziny. Testy integracyjne, które faktycznie integrują się z innymi systemami, są uruchamiane przed wydaniem. –

+0

@SimonWhitehead: dlaczego używamy wzorca repozytorium, czy jest to potrzebne i jaka jest różnica między udawaniem i fałszowaniem? – neel

+0

* Po tym chcę przetestować operacje CRUD * Chcesz przetestować swoją logikę związaną z operacjami CRUD lub chcesz przetestować struktura podmiotu? –

Odpowiedz

5

Aby przetestować funkcjonalność EF, zalecam pisanie testów integracji przeciwko znanym danym. Wspólne podejście jest budowanie dane jako część testu jako warunek wstępny do swoich testów swojej wybranej funkcjonalności w oparciu o:

Ex:

  1. Włóż znane dane

  2. Run wybierz funkcjonalność przed znanymi danych wynika

  3. Assert

Powyższe kroki przetestują zarówno zapytania, jak i wiązania/model EF.

Logika biznesowa, która działa na dane zwracane z EF, powinna wyodrębnić logikę EF poprzez kpiny. Umożliwi to pisanie testów jednostkowych, które foucują się podczas testowania logiki bez martwienia się o zależności punktów/danych integracji.

+1

tylko po to, aby dodać możliwy punkt 4. zamknąć każdy test w transakcji, która została wycofana na końcu - w ten sposób pozostawisz DB czyste po wykonaniu testu –

2

Można również przetestować model EF z bazą danych w pamięci. Here is an example korzystania z programu Effort jako bazy danych do testów jednostkowych.

+0

Link jest martwy –

5

Schematy repozytorium i jednostki pracy mają na celu utworzenie warstwy abstrakcji między warstwą dostępu do danych a warstwą logiki biznesowej aplikacji. Implementacja tych wzorców może pomóc w izolacji aplikacji od zmian w składnicy danych i może ułatwić zautomatyzowane testowanie jednostek lub rozwój oparty na testach (TDD).

Po prostu przejrzyj Here, aby uzyskać wyjaśnienie na przykładzie.

16

Powiedzmy, że masz 2 warstwy rozwiązanie

MyApp.Web

MyApp.Data

W swojej warstwie danych trzeba będzie coś takiego:

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

gdzie IProductsRepository to

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

W MyApp.Web trend polega na tym.

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) 
    } 
} 

Kto umieszcza w ProductsRepository do konstruktora w czasie wykonywania? Ludzie używają wtrysku zależności takich jak Ninject frameworków do tego. Ale dlaczego? Bo to pozwala im na podróbkę ProductsRepository i jak to

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

a następnie testów jednostkowych, regulator jak ten

[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); 
} 

istocie jesteś udaje bazę więc test jednostka jest szybko i niezależnie od bazy danych. Czasami, aby udawać ludzi, używaj modelu do szyderstwa:, takiego jak Moq, który zasadniczo robi to samo.

Jeśli chcesz przetestować produkt ProductsRepository, to nie jest już nazywany testem jednostkowym, ponieważ zależy od zewnętrznego źródła. Aby przetestować te, w zasadzie testujesz Entityframework.

W połączeniu z testami jednostkowymi ludzie przeprowadzają testy integracyjne za pomocą struktur takich jak Specflow. Zasadniczo można utworzyć instancję Controler produktów za pomocą rzeczywistego produktu ProductsRepository i sprawdzić wyniki wracające.

Powiązane problemy