Единичное тестирование и структура объекта

Question

Я очень новичок в EF, я хочу знать, что является лучшим способом создания EF с базой данных SQL Server. После этого я хочу проверить операции CRUD. Является ли EF реализованным методом TDD, и меня путают эти шаблоны репозитория, макет контекста, поддельный шаблон и т. Д.

CRUD-операции в EF, что все будет проверено? (DbContext, SaveChanges() ... необходимо проверить?)

Итак, любые идеи, как выполнить модульное тестирование с компонентами на основе Entity Framework? (Я проверяю все это в Visual Studio 2012, ASP.NET MVC4)

Answer 1

Чтобы проверить функциональность EF, я рекомендую написать тесты интеграции с известными данными. Общий подход заключается в создании данных в рамках теста в качестве предварительного условия для ваших испытаний вашего выбора на основе функциональных возможностей:

Ex:

1. Вставка известные данные

2. Run выберите функции против известных данных результатов

3. Утверждая

Вышеупомянутые шаги проведут проверку ваших запросов и привязок/моделей EF.

Бизнес-логика, действующая на данные, возвращаемые из EF, должна абстрагировать логику EF посредством насмешек. Это позволит вам писать модульные тесты, которые проверяют только логику, не беспокоясь о точках интеграции/зависимостях данных.

Answer 2

Вы также можете протестировать свою модель EF с помощью базы данных в памяти. Here is an example Использование Усилия как базы данных для модульных тестов.

Answer 3

Репозиторий и блок рабочих шаблонов предназначены для создания слоя абстракции между уровнем доступа к данным и уровнем бизнес-логики приложения. Реализация этих шаблонов может помочь изолировать ваше приложение от изменений в хранилище данных и может облегчить автоматическое модульное тестирование или тестовую разработку (TDD).

Просто пошли Here для объяснения с помощью примера.

Answer 4

Допустим, у вас есть два слоя раствора

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" } 
      }, 
    } 
} 

, а затем БЛОК TEST контроллер как этого

[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. По существу, вы можете создать экземпляр Productscontroller с реальными ProductsRepository и проверить результаты.