Stream filter already registered

[pravednik]

С письменным английским тяжело, посему отпишу по-русски.

При создании модульных тестов для приложения наткнулся на забавный момент:
в setUp() всё отлично инициализируется, но только в первой итерации тестов. Как только внутри PHPUnit вызывается setUp для следующего теста, ловим исключение о зарегистрированном потоке.
Очевидно, что в tearDown() поток не освобождается.

Трейс исключения: http://www.everfall.com/paste/id.php?ui2dua77pkop

И ещё 1 момент: в Go\Core\AspectKernel неплохо было бы добавить метод resetInstance всё для того же тестирования с помощью PHPUnit (привет синглтонам)

[lisachenko]

Я сегодня добрался до компа и просмотрел ваш трейс, есть ощущение, что у вас не совсем все правильно с реализацией подключения АОП.

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

[pravednik]

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

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

[lisachenko]

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

И еще один момент - у вас юнит-тесты или функциональные? Если юнит-тесты, то вы определенно делаете что-то не так, вы должны лишь протестировать ту функциональность, которая есть в вашем коде, без учета аспектов. А также потом отдельно проверить код самих аспектов на предмет того, что они работают корректно. Задача тестирования ядра АОП и внутренних фильтров - должна быть в самом фреймворке.

Как вариант - подправьте инициализацию в своем тесте с динамической setUp() на статическую: public static function setUpBeforeClass().

[pravednik]

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

[lisachenko]

Отлично, рад, что у вас все получилось )