Должен ли я выполнить модульный тест уровня доступа к данным?Это хорошая практика и как это сделать?

Question

Если у меня есть уровень доступа к данным (nHibernate), например, класс с именем UserProvider и класс бизнес-логики UserBl, я должен проверить оба их метода SaveUser или GetUserById или любой другой открытый метод в слое DA, который вызывается из BLслой.Это избыточность или обычная практика?

Является ли это общим для уровня DA модульного тестирования или относится к области тестирования интеграции?Лучше иметь тестовую базу данных или создать базу данных во время теста?

Любая помощь приветствуется.

Answer 1

Нет правильного ответа на это, это действительно зависит.Некоторые люди (например, Рой Ошерове ) говорят, что вам следует тестировать только код, имеющий условную логику (операторы IF и т. Д.), Который может включать или не включать ваш DAL.Некоторые люди (часто те, кто занимается TDD) скажут, что вы должны протестировать все, в том числе DAL, и стремиться к 100% охвату кода.

Лично я проверяю его только при наличии логики, поэтому в итоге получим немного DALметоды проверены, а некоторые нет.В большинстве случаев вы просто проверяете, что ваш BL вызывает ваш DAL, что имеет свои достоинства, но я не нахожу нужным.Я думаю, что имеет больше смысла иметь интеграционные тесты, охватывающие комплексное приложение, включая базу данных, которая охватывает такие вещи, как GetUserById.

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

Answer 2

По моему опыту было полезно протестировать каждый слой отдельно. Интегрируем и тестируем снова. Интеграционный тест обычно не проверяет все аспекты. Иногда, если уровень доступа к данным (я не знаю nHibernate) генерируется код или что-то вроде общего кода, это выглядит как избыточное. Но я неоднократно видел, что систематическое тестирование окупается.

Это избыточность? По моему это не так.

Это обычная практика? Трудно сказать. Я бы сказал нет. Я видел это в некоторых проектах, но не во всех проектах, в которых я работал. Часто зависел от времени / ресурсов и менталитета команды / индивидуального разработчика.

Лучше ли иметь тестовую базу данных или создавать базу данных во время теста? Это совсем другой вопрос. Нельзя легко ответить. Зависит от вашего проекта. Создать новый хорошо, но иногда выкидывает нереальные ошибки (хотя ошибки). Это зависит от вашего проекта (разработка продукта или разработка собственной разработки). Обычно в проприетарной разработке сайтов база данных переносится откуда-то. Таким образом, второй тест, безусловно, необходим с перенесенными данными. Но это скорее на уровне системного тестирования.

Answer 3

Хорошей практикой является написание модульного теста для каждого слоя, даже DAL.

Я не думаю, что запуск тестов на реальном БД - это хорошая идея, вы можете испортить важные данные. Мы использовали для создания копии базы данных для тестов с достаточным количеством данных для запуска тестов. В нашем тестовом проекте у нас был специальный файл web.config с настройками теста, например ConnectionString для нашей тестовой базы данных.

Answer 4

Модульное тестирование DAL того стоит, как уже упоминалось, если в нем есть логика, например, если для вставки используется тот же StoredProc и обновляется его значение, зная, что вставка работает, последующий вызов обновляет предыдущий, а оператор выбора возвращает его и не список В вашем случае SaveUser метод, вероятно, вставляет в первый раз и затем обновляет, приятно знать, что это делается на этапе модульного тестирования.

Если вы используете инфраструктуру, такую ​​как iBatis или Hibernate, где вы можете реализовать обработчики типов, стоит подтвердить, что обработчики обрабатывают значения способом, который приемлем для вашей базовой БД.

Что касается тестирования на реальной БД, если вы используете среду, подобную Spring, вы можете использовать поддерживаемые классы модульных тестов базы данных с автоматическим откатом транзакций, чтобы вы выполняли свои тесты, и на БД впоследствии не влияли. Смотрите здесь для информации. Другие, вероятно, предлагают аналогичную поддержку.