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