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

Question

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

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

Благодарим вас. :)

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Это так, как это: - проще устанавливать и поддерживать - вы проверяете не только слой DB, но уровень представления, тоже

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

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

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

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