Таблица базы данных обработчика сеансов Zend уничтожается во время теста PHPUnit

Question

Я проводил юнит-тестирование и столкнулся с этой странной и плохой проблемой.

Я провожу проверки подлинности пользователя с некоторыми из моих служб / картографов.

Я сейчас провожу около 307 тестов. Это действительно происходит только тогда, когда я запускаю их все в одной партии.

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

Вот проблема.

Где-то вдоль линии тестов вызывается метод __destruct класса Zend_Session_SaveHandler_DbTable. Я не имею понятия почему? Но это так.

Метод __destruct сделает любую запись в мои объекты сеанса бесполезной, потому что они помечены как доступные только для чтения.

Понятия не имею, почему вызывается метод уничтожения.

Он вызывается за много тестов до моих тестов аутентификации. Если я запускаю каждую папку тестов по отдельности, это не проблема. Это только когда я пытаюсь запустить все 307 тестов. У меня есть некоторые тесты, которые выполняют работу с базой данных, но мой код не закрывает соединения с БД и не разрушает обработчик сохранения.

У кого-нибудь есть идеи о том, почему это происходит и почему мой Zend_Session_SaveHandler_DbTable разрушается? Имеет ли это какое-либо отношение к времени жизни по умолчанию?

Answer 1

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

Zend_Session::$_unitTestEnabled = true;

Answer 2

Я думаю, что происходило то, что PHPUnit делал сборку мусора. Всякий раз, когда я запускал 307 тестов, сборщик мусора должен был запускаться, и он по какой-то причине разрушал таблицу Zend_Session_SaveHandler_DbTable.

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

Или, может быть, именно PHP выполняет сборку мусора, что имеет больше смысла.

В любом случае, мое текущее решение состоит в том, чтобы создать новый объект Zend_Application для каждого класса тестов, чтобы у всех тестов в этом классе был новый объект zend_application для работы.

Вот немного интересной информации.

Я поместил выражение echo в метод __destruct в обработчике сохранения.

Метод вызывался (X + 1) раз, где X - количество выполненных мной тестов. Если я выполнил 50 тестов, я получил 51 эхо, 307 тестов, затем 308 эхо и т. Д.

Вот интересная часть. Если бы я выполнил только несколько тестов, эхо все пришло бы в конце тестового прогона. Если бы я попытался выполнить все 307 тестов, 90 эхо-сигналов появилось бы после того, что, как я предполагал, было 90 тестами. Остальные эхо-сигналы появятся в конце оставшихся тестов. Число эхо-сигналов снова было Х + 1, или в данном случае 308.

Итак, я предполагаю, что это как-то связано с методом tearDown, вызываемым PHPUnit, или с сборщиком мусора PHP. Возможно, PHPUnit вызывает сборщик мусора при разборке. Кто знает, но я рад, что теперь у меня все получилось, потому что все мои тесты проходили заранее.

Если у кого-нибудь из вас есть лучшее решение, дайте мне знать. Может быть, я обнаружил в своем коде, phpunit или zend недостаток, который раньше не был известен, и есть какой-то способ его исправить.