Как настроить тестирование базы данных с помощью фреймворка PHP SimpleTest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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