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

Question

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

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

Какие обычные практики помогают в этом отношении?

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

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

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

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

Answer 1

Решение насмешливое. Издевается над "заменой" соединения. Тестируемый модуль «подключится» к макету и выполнит его оператор. Макет возвращает нормальные наборы результатов o.s.e.

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

Как сказал другой: соединение с БД не является модульным тестом. Так что бросьте его и сделайте это локально с объектами Mocking

Answer 2

Это не юнит-тест, если вы тестируете более одного юнита.

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

Для Java вы также можете заглянуть в dbunit. http://www.dbunit.org/

Answer 8

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

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

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

И так далее, и так далее ... Затраты на модульное тестирование / TDD просто накапливаются со временем.