Как тестировать взаимодействие с БД PHPUnit?

Question

[an23]

Добрый день. Для тестирования кода на PHP я использую PHPUnit.
На данный момент занимаюсь написанием архитектуры приложения, при этом используя шаблон Data Mapper. Соответственно, большинство тестов должно сводится к проверке взаимодействия кода с БД. CRUD операции с сущностью и т.д. Я думаю здесь нужно проверять непосредственно работу с БД, а не заменяться это stub объектами. Является ли вообще тестирование взаимодействия с БД модульным? И как правильно проводить данное тестирование. Использовать ли DBUnit. Опять же как? Спрашиваю не о том, что можно почитать в документации, а конкретно о лучших решениях, которые пришли с опытом. Спасибо!

Answer 1

[TomaZ Vazovsky]

Модульным наверно уже не является. Я бы назвал его "интеграционным", потому что мы тестируем как работает ваш код совместно с базой.
Суть заключается в том, что мы (в случае записи в базу) подаем на вход методу данные, а потом проверяем, что мы получили в базе, причем без использования нашего кода. В случае чтения наоборот, сначала сторонними средствами создаем записи, а потом проверяем, как они прочитаются.
Я в таких тестах всегда поступал следующим образом:
1. Создаем "дата-провайдера" - который в декларативной форме описывает параметры: "что на входе метода" и "что в базе" или "что в базе" и "что на выходе метода".
2. У нас есть прямой доступ к базе, с помощью него в каждом тесте мы либо создаем запись в базе, либо проверяем, что туда записал тестируемый метод.
Но думаю, такими тестами не стоит сильно увлекаться, ведь они по сути просто проверяют, что вы правильно составили запрос.

Comments

[an23]

Тогда вопрос. Сейчас у меня в каждом Mapper классе есть методы типо create, update, которые делают что-то вроде

$values = array(":id" => $obj->getId(),:firstname" => $obj->getFirstName());
$this->updateStmt->execute($values);

т.е. отличаются они только набором полей, соответственно в будущем, я возможно вынесу эти методы в базовый класс, а он уже будет собирать нужный набор полей для определенного класса наследника. Я к тому, что реализация может поменяться и соответственно, если сейчас запрос создается верно, то потом могут возникнуть проблемы. Возможно все таки правильно на этапе Unit тестирования проверять взаимодействие с БД? Чтобы я мог поменять архитектуру и тут же прогнать свои тесты.
Или же мне нужно просто проверять, что в нужном мне методе, просто верно генерируются параметры для запроса, а не сам запрос?

[TomaZ Vazovsky]

Если речь о Unit тестировании, то в этом случае Вы проверяете, что метод именно свою работу выполняет верно. Т.е. создание запроса к базе, или составление параметров для запроса, это уже выполненная им работа. Чтобы проверить все ли так, вместо настоящего соединения с базой мы подсовываем ему "мок". Причем Unit тесты при изменении архитектуры помогают удостоверится, что не поломалась "не затронутая" часть программы. А вот тесты для измененной функциональности все равно придется менять. Больше или меньше в зависимости от того, какой был масштаб изменения кода приложения.
Что же до "интеграционных" тестов, то я использую их в тех случаях, когда хочу удостоверится, что мой "хитрый запрос" в базе делает именно то, что я придумал. Написание теста занимает немного больше времени, чем просто глянуть в базу, но зато помогает ничего не упустить и держать на контроле именно конечную структуру базы, "оптимизируя" методы работы с базой.
Честно говоря, не совсем понимаю, в чем суть вопроса?
Писать или нет Unit теусты? - зависит от времени и средств выделяемых на проект, тесты повышают качество продукта.
Писать или нет именно тесты на работу с базой? - ответ почти такой же, однако важность Unit тестов на критичные места в приложении (формирование запросов, проверки и преобразование входных данных) я бы поставил выше интеграционных тестов с базой. В конечном итоге: чем проще запросы, тем лучше, и тесты могут не понадобиться, а база и так будет работать как описано в документации, у нее есть свои разработчики и свои тесты.