Модульное тестирование с использованием Nunit, Ninject, MVC2 и модели данных объекта ADO.Net - PullRequest
1 голос
/ 15 июля 2010

Я пытаюсь разобраться, используя Nunit, Ninject, MVC2 и модель данных сущности ADO.Net.

Допустим, у меня есть ProductsController, создающий экземпляр класса SqlProductsRepository.

public class ProductsRepository : IProductsRepository
{
    public MyDbEntities _context;

    public ProductsRepository()
    {
        _context = new MyDbEntities();
    }

    public IList<Product> GetAllProducts()
    {
        return (from p in _context.Products select p).ToList();
    }
}

public class ProductsController : Controller
{
    public ActionResult ProductsList()
    {
        ProductsRepository r = new ProductsRepository();
        var products = r.GetAllProducts();

        return View(products);
    }
}

Я хотел бы иметь возможность выполнить модульное тестирование в ProductsRepository, чтобы убедиться, что оно возвращает правильные данные, но я не уверен, как написать тестовый класс.

Каждый учебник / документ, который я до сих пор читал, указывает мне на создание объекта Mock с использованием IProductsRepository, а затем на внедрение и тестирование контроллера.

Мне кажется, это обходит конкретную реализацию.

MyDbEntities происходит от модели данных сущностей ADO.Net .edmx

Ответы [ 3 ]

3 голосов
/ 15 июля 2010

Вы совершенно правы - издевательство над хранилищем обходит конкретную реализацию.В этом-то и дело.

Модульное тестирование - это не то же самое, что функциональное тестирование.Ваш фиктивный объект может быть настроен так, чтобы он возвращал то, что вы явно указали, затем вы проверяете, чтобы постоянные входные данные из вашего фиктивного приводили к ожидаемым результатам.

2 голосов
/ 15 июля 2010

С двумя вашими классами (ProductsRepository, ProductsController) у вас должно быть два набора тестов.Один набор тестов для каждого класса.

При (модульном) тестировании ProductsController вы должны смоделировать его зависимости (в данном случае, IProductsRepository).Обойти конкретную реализацию зависимостей имеет смысл.

Будет совершенно другой набор (интеграционных) тестов для проверки того, что ProductsRepository может обращаться к базе данных и возвращать правильные данные.В этих интеграционных тестах вы ничего не будете издеваться, поскольку вы проверяете взаимодействие между real хранилищем и фактической базой данных.

2 голосов
/ 15 июля 2010

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

Именно при модульном тестировании контроллера вы захотите издеваться над репозиторием Products.

В моих интеграционных тестах для ProductsRepository я делал очевидные вещи, такие как

public void TestProductsRepository()
{
  var context = new MyDbEntities();

  // add a new product

  var products = context.GetAllProducts();

  // check products contains new product
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...