Единичное тестирование и структура сущностей

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

Операции CRUD в EF, что все вещи будут проверены? (DbContext, SaveChanges()... нужно проверить?)

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

Ответ 1

Допустим, у вас есть двухслойное решение

MyApp.Web

MyApp.DataSTRONG >

В вашем слое данных у вас будет что-то вроде этого:

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

а затем UNIT 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);
 }

По существу, вы подделываете базу данных, поэтому unit test работает быстро и независимо от базы данных. Иногда для подделки люди используют mocking framework как Moq, что по сути делает то же самое.

Если вы хотите протестировать ProductsRepository, то он больше не называется unit test, потому что он зависит от внешнего источника. Чтобы проверить те, вы по существу проверяете Entityframework.

В сочетании с модульными тестами люди проводят тестирование интеграции с использованием таких фреймворков, как Specflow. По существу вы можете создать Productcontroller с помощью реального ProductsRepository и проверить результаты.

Ответ 2

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

Пример:

Вставить известные данные
Выполнить функцию выбора для известных данных
Результаты утверждения

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

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

Ответ 3

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

Просто перейдите Здесь для объяснения с помощью exsample.

Ответ 4

Вы также можете протестировать свою модель EF с базой данных в памяти. Вот пример использования Effort в качестве базы данных для модульных тестов.