Как настроить тестирование базы данных с использованием PHP SimpleTest Framework

Question

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

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

Спасибо, любезно. :)

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

Я думаю, что вы должны использовать ORM и написать для этого несколько интеграционных тестов. Если интеграционные тесты показывают, что он отлично работает в реальной среде, вам придется тестировать его снова только при изменении среды (базы данных, версии php, платформы и т. Д.). После этого вы можете макетировать объект ORM, и вам не нужно будет подключаться к базе данных.

Так что я думаю, что это лучший способ, но если вы не хотите использовать ORM, вы можете создать тестовую базу данных и смоделировать объект подключения к базе данных (PDO). В этом случае вы можете создавать и удалять тестовые таблицы в разделах setUp и tearDown ваших testCases. Важно, чтобы это были интеграционные тесты, а не модульные тесты, поэтому вам не нужно запускать их всегда, только когда что-то изменилось между PHP и SQL-сервером. После того, как вы проверили свои объекты доступа к данным с помощью интеграционных тестов, вы должны смоделировать их в своих модульных тестах.

Answer 5

Если вы действительно хотите провести тестирование на базе данных, я бы рекомендовал импортировать данные / создавать таблицы перед каждым тестом. Таким образом, ваша база данных начинается с известного состояния в каждом тесте. Поскольку это довольно дорого по производительности, вы можете начать транзакцию (при условии, что ваш rdms поддерживает ее) в setUp и откат в tearDown. MySql (которая, вероятно, является используемой СУБД), не поддерживает вложенные транзакции, поэтому, если тестируемый код использует транзакции, вы можете столкнуться с проблемами. Вы можете обойти это, используя savepoints . Установите точку сохранения перед тестированием и выполните откат к точке сохранения после теста.

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

Answer 6

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

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

Так оно и есть: - проще в настройке и обслуживании - вы проверяете не только уровень БД, но и уровень представления

Тем не менее, если у вас есть хранимые процедуры в вашей БД, делайте используйте SimpleTest - я сделал это сам успешно. По сути, создайте SimpleTests, которые начинаются с известного состояния БД, затем выполните несколько INSERTS / UPDATES, затем запустите сохраненный процесс и убедитесь, что состояние БД соответствует ожидаемому.

Answer 7

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

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

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

Answer 8

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

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