2016-02-03 4 views
0

Я тестирую действие контроллера с помощью функционального теста в Symfony. В этом тесте я делаю что-то вроде этого:Как проверить в функциональном тесте, если событие отправлено

$client->request(
    'PUT', 
    '/api/nodes/', 
    $data 
); 

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

$client->enableProfiler(); 
$client->request(
    'PUT', 
    '/api/nodes/' . $data[0]['id'] . '?webspace=sulu_io&language=en', 
    $data[0] 
); 

/** @var EventDataCollector $eventDataCollector */ 
$eventDataCollector = $client->getProfile()->getCollector('events'); 

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

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

ответ

2

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

+0

Пытался сделать это с помощью '$ client-> get ('event_dispatcher') -> addEventListener (...)', но с некоторого времени я испытываю проблемы, которые ядро, кажется, сбрасывается для каждого запроса ... Было бы хорошо чтобы включить только этого слушателя в этот единственный тест, я думаю, вы предлагаете добавить слушателя через конфигурацию, правильно? –

+0

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

1

Yagni. Функциональные тесты должны основываться на спецификациях, например. отправка некоторых данных в PUT /api/nodes/ HTTP/1.1 должна приводить к чему-то (идеально) ценному для пользователей API. Я полагаю, некоторые манипуляции с данными. Тест должен подтвердить, что результат соответствует ожиданиям для конкретных перестановок данных.

Слушание событий - это внутренняя реализация вашего черного ящика и не является предметом функционального тестирования. Его следует тестировать изолированно. Включая профилировщик, вы в основном меняете тестируемую систему и завершаете тестирование того, что только частично связано с производственным кодом.

+0

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

+0

А, я вижу. Затем вам нужно издеваться над потребителем четного и утверждать, что он вызывается. –

Смежные вопросы