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

Ответ 1

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

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

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

Ответ 2

Хорошей практикой является запись unit test для каждого слоя, даже DAL.

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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