Интеграционное тестирование вывода операции фильтра для магазина - PullRequest
Новая
       22

Интеграционное тестирование вывода операции фильтра для магазина

1 голос
/ 07 августа 2011

Я хочу запустить интеграционные тесты для фильтров моего магазина, например,

Я фильтрую по цене и по другим атрибутам товара

Существуют ли шаблоны или рекомендации по утверждению такого теста, я проиллюстрирую пример:

Скажем, я вызываю Repository.GetOnlyTShirtsWithColorRed () в моей тестовой базе данных. У меня есть все возможные типы элементов.

Я могу получить более 1 предмета назад, но я хочу утверждать, что у них всех есть Красный цвет , и они все Футболки

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

Ответы [ 3 ]

0 голосов
/ 08 августа 2011

Из того, что я прочитал - вы хотите проверить, что ваша реализация репозитория работает с реальной БД - иначе интеграционные тесты.

Если вышеприведенное верно, я думаю, вы на правильном пути.Мой аргумент, вероятно, будет выглядеть так: 

Assert.That(shirtsFromRepo.All(shirt => shirt.Color == Colors.Red), "all shirts were not red!)

Что касается "наилучшей практики", можете ли вы опубликовать ссылку?

AFAIK единственная рекомендация - избегать сложной логики в вашем коде (например, ifsи другие управляющие структуры) и тестирование по одному на тест.

0 голосов
/ 09 августа 2011

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

Однако такие тесты стоят дорого, и сами по себе не являются юнит-тестами. Чтобы повысить производительность и довести время выполнения до приемлемых значений, вы можете захотеть работать с базой данных в памяти, такой как SQLite . Это бесплатно, кстати.

Таким образом, вам не придется зацикливаться или перебирать тесты. Вы просто позвоните в свой репозиторий и подтвердите результаты: 

public void GetShirts_WithFilter_ShouldReturnFilteredResults()
{
    var rep = new MyRepository(mySQLiteConnectionString);

    var redShirts = rep.GetShirts(shirt => shirt.Color == Color.Red); //For example

    Assert.AreEqual(3, redShirts); // I know there should be 3 red shirts in the table
}

В качестве альтернативы вы можете подготовить коллекцию (например, IEnumerable of Shirt) со списком точных рубашек, которые вы ожидаете получить, и заявить, что списки имеют одинаковые элементы.

Надеюсь, это поможет.

0 голосов
/ 08 августа 2011

Лучший способ проверить это - макетировать репозиторий : заменив базу данных (или веб-службу и т. Д.) Консервированной коллекцией (массивом, списком), вы можете точно контролировать, сколькокрасные футболки, которые есть в вашем хранилище, поэтому вы можете указать своему тесту ожидать точно конкретной коллекции.
В C #, например, это может выглядеть так: 

public void GetRedTShirts_ReturnsAllItems()
{
    Shirt[] allShirts = { new Shirt(Red), new Shirt(Green), new Shirt(Red) }; //collection for mock
    // This depends on your mocking framework
    var mockShirtRepository = new Mock<Shirt>(allShirts); 
    var expectedCount = 2;
    // example of using dependency injection to replace the repository your controller would usually use in production, with a mock
    var businessLogic = new Controller(mockShirtRepository.object);

    var result = businessLogic.GetOnlyTShirtsWithColorRed();
    Assert.AreEqual(2, result);
}

Таким образом, вы проверяете свою логику фильтрации, используя детерминированный, известный репозиторий, который не может быть разрушен вашим репозиторием.

...