Уровень бизнес-логики уровня тестирования

Question

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

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

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

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

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

Marco

Answer 1

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

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

Я написал об этом в Using Transactions for Unit Tests в своем блоге. Пример кода для linq-to-sql, но тот же подход работает и для инфраструктуры сущностей.

Answer 2

Да,

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

Вы правы.

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

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

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

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

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

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