Уровень бизнес-логики модульных тестов

Question

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

Я бы тоже хотел представить сервер CI, но это будет темой других вопросов.Теперь вопрос: я сейчас читаю «Искусство модульного тестирования» (это рекомендуемый шедевр!), И автор подчеркивает, что модульное тестирование отличается от интеграционного тестирования.Это ясно для меня, и, если я правильно понял, модульное тестирование Business Logic не должно зависеть от соединений с базой данных и так далее.Прежде всего: я прав?

Итак, предположим, что я прав (то есть, когда я тестирую свой BLL, я должен заглушить базу данных), как я это сделаю?Я читал, что есть некоторые рамки для дб издевательства.Должен ли я использовать один из них?Что вы используете?

Следующий вопрос: вы действительно думаете, что это правильный способ сделать?Я имею в виду: в моем проекте BL взаимодействует с базой данных через Entity Framework.Так, например, когда вызывается метод «UpdateItem» в моем BLL, он что-то делает, а затем сохраняет ObjectContext.Этот ObjectContext является зависимостью Entity Framework, которую мне нужно удалить в моем BL.Но что я должен проверить в таком методе?Я действительно не могу понять модульное тестирование слоя BL без совместного тестирования DAL ... Можете привести пример?

Большое спасибо за ваши усилия!

Марко

Answer 1

Да,

Тестирование модуля Business Logic не должно зависеть от базы данных

Вы правы в этом.

Я рекомендую вам:

• использовать набор модульных тестов для бизнес-уровня, используя заглушки вместо реальных вызовов БД.Вы можете заглушить БД любым удобным для вас способом (у вас есть поддельные классы или фиктивные библиотеки) при условии, что у вас есть абстракции над компонентами БД.
• использует набор интеграционных тестов для проверки реальных вызовов БД (итолько это!)

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

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

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

Кроме того, я предлагаю вам прочитать книгу, которую вы упомянули.По-моему, это очень важный источник информации по этой теме.

Answer 2

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

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

Я писал об этом в Использование транзакций для модульных тестов в моем блоге.Пример кода есть для linq-to-sql, но тот же подход работает и для структуры сущностей.