Это типичный опыт модульного тестирования?

Question

Я написал 220-строчный класс с 5 открытыми методами. У меня есть класс модульного тестирования, который выполняет 28 тестов для этого класса, который занимает более 1200 строк кода, но это в основном из-за повторяющегося кода, используемого при настройке тестов. Этот код тестирует DAL в моем проекте, чтобы убедиться, что он правильно взаимодействует с базой данных и что хранимые процедуры работают правильно. Кажется, я проделал большую работу, чтобы протестировать очень мало кода. Я использую насмешки с насмешками Rhino, чтобы по возможности не писать свои заглушки.

Это типичный опыт модульного тестирования?

Answer 1

Каким образом это типично?

Если вы имеете в виду, что у вас больше кода модульного теста, чем реального кода, тогда да.Но вы должны относиться к своему коду модульного теста так же, как к своему «реальному» коду: вы должны удалить дубликаты и реорганизовать их, пока они не станут настолько простыми, насколько это возможно / желательно.

Также, если вы тестируете DAL ивзаимодействие с реальной базой данных, то, что у вас есть, это интеграционный тест.

РЕДАКТИРОВАНИЕ

Я недавно приступил к написанию базовых классов модульных тестов для общих шаблонов тестирования.У меня есть много кода установки и вспомогательных методов там.Мой последний базовый класс модульных тестов - это общий, который позволяет мне очень легко тестировать классы wcf-web-api.Итак, мои настоящие тестовые классы очень скудные и «точные».YMMV

Answer 2

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

Тем не менее, тестирование DAL с точки зрения взаимодействия с базой данных и проверки, вызваны ли правильные процедуры, пахнет как интеграционный тест.Вы можете переосмыслить то, что вы хотите сделать.При модульном тестировании все разговоры с БД должны быть смоделированы / заглушки.

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

Редактировать:

Просто чтобы добавить пример того, что другие делают это также.Вы можете проверить источники Aggregate и AggregateTests классов из Edulinq проекта.15 тестов для тестирования 3 открытых методов, причем класс тестов в два раза больше, чем тестируемый.

Answer 3

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

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

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

С 28 тестами ваши 1200 строк уменьшаются примерно до 43 за тест. Учитывая, что вы повторяете свой установочный код, это вполне разумно.

Answer 4

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

Answer 5

28 тестов для одного класса звучит так, как будто класс делает слишком много вещей.