Несогласованные модульные тесты - сбой в наборе тестов, прохождение отдельных

У меня есть модульные тесты для контроллеров Zend Framework, расширяющие Zend_Test_PHPUnit_ControllerTestCase.

Тесты отправляют действие, которое перенаправляется к другому действию, например:

// AdminControllerTest.php

public testAdminAction()    
   $this->dispath('/admin/index/index');
   // forwards to login page
   $this->assertModule('user');
   $this->assertController('profile');
   $this->assertController('login');
   $this->assertResponseCode(401);
}

// NewsControllerTest.php

public testIndexAction()
{
     $this->dispatch('/news/index/index');
     $this->assertModule('news');
     $this->assertController('index');
     $this->assertController('index');
     $this->assertResponseCode(200);

}

Оба теста проходят успешно, когда они запускаются как отдельные тесты.
Когда я запускаю их в одном и том же наборе тестов, второй терпит неудачу.
Вместо отправки /news/index/index отправляется предыдущий запрос (пользовательский модуль).

Как отследить этот баг? Похоже, у меня есть какое-то глобальное состояние где-то в приложении, но я не могу его отладить. Как я могу сбросить объекты между тестами в наборе? setUpBefore/AfterClass являются статическими, поэтому данных об экземплярах объекта не так много.

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

Вся настройка модульного теста более или менее похожа на описанную в: Тестирование приложений Zend Framework MVC — phly, boy, phly или Тестирование контроллеров Zend Framework, Федерико Каргнелутти.

Решение:

Я определил проблему (после небольшого сна). Проблема была не в настройке модульного теста, а в тестируемом коде.

Я использую разные объекты ACL на основе имени модуля. Какой из них использовать, определял помощник статического вызова к действию, который кэшировал результат в частной статической переменной для ускорения работы. Этот кеш выполнялся только при запуске в наборе тестов. Мне просто нужно больше модульных тестов для этого кода :)

(Извините за такой мусорный пост, но я застрял с этим на день, и я надеялся, что кто-то еще сталкивался с подобным гейзенбагом с модульными тестами в целом)


unit-testing integration-testing phpunit zend-framework
person takeshin    schedule 14.03.2011    source источник
comment
Я не знаю, помогает ли это, но возможно, что когда вы запускаете их по отдельности, вы запускаете setUp() для каждого отдельного теста, а в наборе тестов у вас есть метод setUp(), который может запускаться только один раз перед всеми тестами. проходят испытания. Я не знаком с технологиями, которые вы используете, но просто указываю на возможный общий источник проблем. Удачи!   -  person Luis Miguel Serrano    schedule 15.03.2011
comment
Я предполагаю, что вы используете Zend ControllerTestCase. Можете ли вы опубликовать свой код начальной загрузки, как в тестовом примере, так и в том, что он вызывает? Используете ли вы собственный базовый тестовый пример, который является подклассом CTC и который является подклассом тестовых случаев?   -  person David Harkness    schedule 15.03.2011
comment
Помехи при тестировании — это обычная головная боль, которую необходимо решать в каждом конкретном случае. Для наших проектов я создал SetupAction, зарегистрированные с TestListener реализацией, которые выполняют глобальные setUp и tearDown операции для сброса статического состояния после каждого теста. Мы используем их в тех случаях, когда слишком сложно отследить, какие тесты в конечном итоге устанавливают эти состояния, и их сброс стоит так мало.   -  person David Harkness    schedule 15.03.2011

Ответы (1)


arrow_upward
1
arrow_downward

Вы можете попробовать очистить объектыrequest и response перед отправкой каждого действия, например:

$this->resetRequest()
     ->resetResponse()
     ->dispatch('/news/index/index');
person Vika    schedule 14.03.2011
comment
Это не помогает. Я уже сбросил их в разных местах. - person takeshin; 15.03.2011
comment
В любом случае, спасибо, что нашли время ответить. Я обновил свой исходный пост фактическим решением. - person takeshin; 15.03.2011