Краткий ответ: Прочтите статью Fine Manual по тестированию базы данных в руководстве по PHPUnit .
А теперь длинный ответ ...
Первоепомнить о модульном тестировании - это то, что оно должно быть выполнено в изоляции от всех других компонентов.Часто эта цель упрощается с помощью методов инверсии управления (IoC), таких как внедрение зависимостей wikipedia .Когда ваши классы явно запрашивают свои зависимости в методах конструктора, это простая операция mock phpunit этих зависимостей, чтобы вы могли протестировать оставшийся код изолированно.
Тестирование кода, взаимодействующего с моделями, немного отличается.Обычно нецелесообразно или нецелесообразно вводить ваши модели в тот класс, в котором вам нужен доступ к ним.Ваши модели, как правило, представляют собой «глупые» структуры данных, которые предоставляют ограниченные возможности или не имеют никаких возможностей.В результате, как правило, приемлемо (с точки зрения тестируемости) создавать экземпляры ваших моделей на лету в классах, введенных другим способом.К сожалению, это затрудняет тестирование кода базы данных, потому что, как отмечается в документации PHPUnit:
[T] база данных по сути является глобальной входной переменной для вашего кода
Так какВы изолируете и протестируете код, который взаимодействует с базой данных, если модели не вводятся напрямую?Самый простой способ сделать это - использовать тестовые приборы phpunit .
Поскольку вы определенно уже используете PDO или ORMДля библиотеки, основанной на PDO (верно?), настройка приборов так же проста, как заполнение базовой базы данных SQLite или XML-файла данными для соответствия вашим тестовым сценариям и использование этого специального соединения с базой данных при тестировании кода, взаимодействующего сбаза данных.Вы можете указать это соединение в своем файле начальной загрузки PHPUnit, но, вероятно, более семантически целесообразно настроить PHPUnit Database TestCase phpunit .
общепринятые рекомендации по тестированию кода БД (они также отражены в документации PHPUnit по тестированию БД):
- Настройка приспособления
- Система упражнений при тестировании
- Проверка результата
- Разрушение
Итак, подведем итог: все, что вам нужно сделать, это создать «фиктивный» фиксатор базы данных и заставить ваш код взаимодействовать с этими известными данными вместо фактических данных.База данных, которую вы будете использовать в производстве.Этот метод позволяет успешно изолировать тестируемый код, поскольку он работает с известными данными, и это означает, что вы можете делать конкретные / проверяемые утверждения о результатах ваших операций с базой данных.
UPDATE
Только потому, что это чрезвычайно полезное руководство для того, что не делать в вашем коде, если вы хотите повысить тестируемость, я добавляю ссылку на Misko Hevery's Как написать 3v1L,Нестабильный код .В частности, он не связан с тестированием баз данных, но, тем не менее, полезен.Удачного тестирования!
ОБНОВЛЕНИЕ 2
Я хотел ответить на комментарий об отложении тестирования модели, потому что существующая кодовая база не реализует PDO для доступа к базе данных:
Ваши модели не должны использовать PDO для реализации расширения PHPUnit DbUnit.
Это сделает вашу жизнь немного проще, если вы используете PDO, но вы нене требуется для этогоСкажем, например, вы создали свое приложение с помощью встроенных в PHP pg_* PostgreSQL функций.PHPUnit по-прежнему позволяет вам указывать приборы и может перестраивать их для каждого теста - вам просто нужно указать ваше соединение при выполнении тестов на тот же ресурс, который расширение DbUnit использует для своего прибора.