Блог

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

Я ищу любые предложения относительно лучших методов тестирования кода бд в приложении PHP. Примеры действительно замечательные. Сайты для дальнейшего чтения-это здорово.

Большое вам спасибо. 🙂

Это старый вопрос, но я подумал, что хотел бы добавить некоторый конкретный опыт, который у нас был с этим.

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

У нас есть набор классов, которые являются самыми простыми для обеспечения этой функциональности. Это работает примерно так:

• Инструкции по созданию каждой таблицы базы данных хранятся в файле по адресу tests/etc/schemas/table.sql . Он содержит данные схемы, а также вставки для всех сохраненных данных, которые, как ожидается, найдет тест.
• Каждый тест, требующий наличия базы данных, расширяет Test_DbCase класс, предоставляющий функциональные возможности для построения таблиц.
• Класс начальной загрузки заботится о создании и удалении базы данных при построении и уничтожении.
• Во время выполнения тест вызывает loadTables('foo', 'bar') метод установки для выполнения команд sql в foo.sql и bar.sql .
• Тесты выполняются на основе сохраненных данных … остальное очевидно.

Еще один инструмент, который у нас есть, — это скрипт bash, который упрощает создание table.sql файлов. Это действительно удобно, потому что в противном случае мы бы писали SQL вручную — вы можете взять существующий набор таблиц, настроить все свои данные в MySQL, а затем экспортировать их для создания тестовых файлов в основном.

Это действительно хорошо работает для нас, хотя в конечном итоге нам пришлось многое сделать самим.

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

Затем перед каждым тестом вы TRUNCATE проверяете каждую таблицу. Это намного быстрее, чем удаление/создание таблиц или самой базы данных.

Примечание: Не усекайте после тестов! Таким образом, в случае сбоя теста у вас есть текущее состояние базы данных, которое часто помогает диагностировать проблему.

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

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

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

При тестировании кода базы данных полезно всегда иметь ту же базу данных, что и в качестве отправной точки. Особенно, если вы проводите модульное тестирование (что, я полагаю, имеет место здесь). Один из способов-усечь все таблицы, как предложил Джейсон, но я предпочитаю иметь в них некоторые исходные данные. Вы знаете, вам всегда нужно иметь какие-то данные «по умолчанию», которые присутствуют в каждой базе данных.

Кроме того, некоторые тесты имеют смысл только при полной базе данных. Поэтому создайте специальный экземпляр базы данных для этих тестов. У меня есть около 3 или 4 различных баз данных, которые я подключаю (просто скопируйте файлы) перед выполнением некоторых тестов. Наличие одной и той же начальной точки каждый раз обеспечивает повторяемость.

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

Я бы посоветовал вам не пытаться протестировать код доступа к базе данных с помощью SimpleTest.

Вместо этого создайте функциональный тест для своего приложения, используя, например, Selenium: запишите тестовый случай, когда вы начинаете с известного состояния базы данных; затем добавьте комментарий и проверьте (используя утверждения Selenium), что содержимое действительно есть.

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

Тем не менее, если у вас есть хранимые процедуры в вашей БД, используйте SimpleTest — я сам успешно это сделал. В принципе, создайте простые тесты, которые начинаются с известного состояния БД, затем выполните несколько ВСТАВОК/ОБНОВЛЕНИЙ, затем запустите сохраненный процесс и убедитесь, что состояние БД соответствует ожидаемому.