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

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

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

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

Это избыточность? На мой взгляд, это не так.

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

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

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

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

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

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

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

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