Как избежать дублирования BusinessLogic в интеграционных тестах

Question

У меня есть один метод веб-сервиса, который возвращает историю изменений продукта, его подпись выглядит следующим образом:

List<MyProduct> GetProductHistory(int iProductId);

Я хотел бы создать тест INTEGRATION для этого метода.Для этого мне нужно создать некоторые данные в БД.Здесь я могу создать функцию, которая записывает некоторые «жестко запрограммированные» записи в БД, которые будут имитировать историю изменений продукта.

Мне также нужно протестировать другую функцию (int GetProductAverageValue (int iProductId)), которая должна выполнять некоторые данныеобработка с использованием информации об истории продукта.Чтобы протестировать эту функцию, мне нужно иметь несколько наборов записей (несколько разных типов истории).И здесь у меня есть несколько вариантов:

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

1-й вариант очень страшен, 2-й - приводит к дублированию бизнес-логики наСлой интеграционных тестов ...

Пожалуйста, сообщите.Любые мысли приветствуются ...

Answer 1

там много данных, поэтому эти наборы немного страшны

Я не совсем понимаю, в чем здесь проблема. Возможно, вы можете уточнить, почему это страшно?

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

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

Answer 2

Вот мой второй вопрос сегодня ... в котором я сам нашел решение, когда закончил написание вопроса.

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

P.S. в любом случае, любые комментарии и предложения приветствуются.