Тестирование модулей в веб-приложениях, использующих базы данных

Я создаю веб-приложение, которое использует базу данных для Пользователей, Безопасность/роли и для хранения контента.

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

Каковы общие практики, которые помогут в этом отношении?

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

Я знаю, что могу создать установку script, что-то, чтобы отменить базы данных и т.д.

Я не хочу тратить все свое время на сохранение моих тестов и гарантировать, что моя база данных находится в sych

Или это стоимость модульного тестирования/TDD?

ОТВЕТЫ

Ответ 1

Это не unit test, если вы тестируете более одного устройства.

Обычно у вас будет один компонент (ваша страница или бизнес-уровень), говорящий с объектом уровня данных, который отвечает за фактическое подключение и запрос к базе данных. Моя рекомендация состоит в том, чтобы разработать unit test для первого компонента, используя инъекцию зависимостей для передачи в макетной версии DataLayer (которая действует на жестко закодированные данные, или List, который вы передаете, и т.д.). Таким образом, вы тестируете свой код более высокого уровня в изоляции от других компонентов.

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

Ответ 2

Решение - Mocking. Mocks "заменяет" соединение. Тестируемое устройство "подключится" к Mock и выполнит его утверждение. Mock возвращает нормальные результаты o.s.e.

После теста макет может предоставить вам список всех методов, которые были вызваны тестируемым устройством. Easymock.org

Как сказано в другом сообщении: Соединение с БД не является unit test. Поэтому оставьте его и сделайте это локально с Mocking objects

Ответ 3

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

Ответ 4

Звучит так, как будто вы действительно хотите проверить функциональность/интеграцию. Для веб-приложений я рекомендую вам посмотреть Selenium или Canoo WebTest.

Это также отлично подходит для автоматизации задач, которые вы выполняете в Интернете. У меня есть набор настроек и отрывной набор, который создает бизнес-объекты и тестирует пользователей через интерфейс администратора, а также тесты для сайта, ориентированного на клиента.

Ответ 5

Michael Feathers утверждает, что тесты, которые общаются с базами данных, по определению не являются модульными тестами. Основной причиной этого является то, что вы поднимаете: модульные тесты должны быть простыми и удобными в работе.

Это не означает, что вы не должны тестировать код базы данных. Но вы не хотите рассматривать их unit. Таким образом, если вы проводите любое тестирование базы данных, вы хотите отделить тесты от остальных модульных тестов.

Ответ 6

Поскольку я использовал Doctrine для моей работы с базой PHP, а так как Doctrine имеет слой абзаца запроса (называемый DQL), я могу обмениваться концами, не беспокоясь о проблемах совместимости. Поэтому в этом случае для моих модульных тестов я бы только в начале моих тестов загружал схему и приборы в SQLlite db, тестировал свои модели и отбрасывал SQLlite db в конце тестирования.

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

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

Ответ 7

Стоимость модульного тестирования /TDD заключается в том, что вам нужно изменить свой дизайн, чтобы у вас было четкое разделение между базой данных и уровнем домена, чтобы вы могли создать фальшивку, которая позволит вам создавать тесты, t попадает в базу данных.

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

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

И так далее и т.д. Стоимость модульного тестирования /TDD просто накапливается с течением времени.