Спасибо за блог. А то в документации это изменение пока не освещено.
Но ограничение как было, так и осталось:
«This approach only works for the stubbing and mocking of static method calls where caller and callee are in the same class.»
Хотя впринципе не понимаю, почему тупо нельзя взять код статического класса, наставить туда маячков и затем вгрузить вместо основного.
Да, я так подумал, наверное вы правы. Рефлексия для проверки значений это плохая идея. Но допустим, в PHP всё ещё практично доступаться к объектам не через методы (кои мы можем застабить), а через свойства. А переопределять значение свойства можно рефлексией.
Вот ещё один пример придумал. Ксть класс, его конструктор берет id, по нему из базы получает данные. Есть метод, он проводит с данными манипуляции и дает что-то на выход. Мы же не будем делать стабы для функции доступа к БД. Скорее всего мы подменим конструктор и заполним свойства требуемыми значениями через рефлексию…
Вот в такой ситуации не понимаю как лучше. Тут два варианта, или подменять внутренние свойства, или делать стаб, который к тестируемому коду вообще отношения не имеет. А вдруг там в конструкторе что-то поменяется и данные он будет тянуть не с БД, а с АПИ. И потом тест упадет, из-за неправильных стабов. То есть тут как ни крути, а они «хрупкие». И даже если соблюдать правильность соглашений при вызове метода, хрупкость получится из-за стабов.
Есть существенное ограничение на статические методы. Впринципе, его можно обойти, если гонять тесты в разных процессах, но в том же PHPUnit оно присутствует.
Кстати, вот хотел спросить о вашем опыте в PHPUnit. Насколько оправдано использование рефлексии для проверки или подстановки разных значений? Вот не могу понять, это хорошая практика, или плохая. С одной стороны, мы с помощью рефлексии можем подставить и подсмотреть нужные значения в класс не дергая его другие методы, и значит, тестировать только один метод. С другой — мы таким образом можем тестировать «коня в вакууме», метод работает, но совершенно не с тем API, с которым используется в коде.
Не-не-не. Настройка Апача убивает любое желание всё изучать дальше.
Честно, я не вижу никакого смысла вручную делать то, что обычно делается или денвером автоматически, или уже настроено на хостингах. Курс по системному администрированию будет в другом семестре )
Та не надо. Был достаточно жесткий каркас, аки Rails.
И компоненты, как ни крути, выпиливать приходилось из общего ядра.
Он был монолитным, но это было даже хорошо ) Каркас приложения не приходилось строить из кубиков.
Ну насчет гибче абстрактнее… Symfony сейчас как раз и продвигается как компоненты.
Вон уже 8ой друпал будет их использовать. В чем там монолитность пока непонятно. ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Вообщем, у меня есть некоторое разочарование. Я надеялся, что в Зенде будут какие-то новые оригинальные архитектурные решения. А их нет (
Все утверждения основаны на опыте и здравом смысле.
Если есть догма «хэлперы для повторного использования» то не верьте ей. Используйте их там где это необходимо. Переносить логику в шаблоны необходимости нет. Точно так же, как сейчас не принято писать яваскрипт в шаблонах, или пардон, SQL-запросы, точно так же, следует выводить любую логику за рамки html-кода. Если так не делать, до говнокода останется всего полшага.
Вот именно. Вы полностью подтверждаете мои слова про бренды!
Вы не заметили, что Симфони2 уже далеко не монолит, а тоже набор компонентов, и наверное, даже более независимых. Посмотрите немного на Symfony2, и на Symfony Components.
Проблема в том, что в Симфони под единым названием существут 2 разных фреймворка и не все ещё это знают.
Они уже и так есть в Symfony2. Интересно, чего Зендовцы переписывают велосипеды?
Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
Думаю, логично было бы как-то поддерживать блоги по тому же программированию, делать для них более либеральные условия. Да, будет много статей от новичков. Зато в комментарии набегут профи и уже благодаря коментам статья будет интересной и полезной всем.
А вообще, фигли, Новый Год. Вдруг Дедушка Мороз придет и сделает Хабр таким, как его хотят видеть прилежные детишки с положительной кармой )
Я согласен, как-то странно смотреть на этот разрыв. Раньше я неохотно голосовал, а теперь прямо понимаю, что это мой социальный долг выводить хорошие посты на главку. Я не против лимита, но на хабре есть много ускоспециализированых топиков, где не хотелось, чтобы судьба поста решалась 10 голосами.
Для новостей, гаджетов, и пр. лимит в +10 кармы оправдан. А вот для остального — нужно смотреть и разбираться.
Но ограничение как было, так и осталось:
«This approach only works for the stubbing and mocking of static method calls where caller and callee are in the same class.»
Хотя впринципе не понимаю, почему тупо нельзя взять код статического класса, наставить туда маячков и затем вгрузить вместо основного.
Да, я так подумал, наверное вы правы. Рефлексия для проверки значений это плохая идея. Но допустим, в PHP всё ещё практично доступаться к объектам не через методы (кои мы можем застабить), а через свойства. А переопределять значение свойства можно рефлексией.
Вот ещё один пример придумал. Ксть класс, его конструктор берет id, по нему из базы получает данные. Есть метод, он проводит с данными манипуляции и дает что-то на выход. Мы же не будем делать стабы для функции доступа к БД. Скорее всего мы подменим конструктор и заполним свойства требуемыми значениями через рефлексию…
Вот в такой ситуации не понимаю как лучше. Тут два варианта, или подменять внутренние свойства, или делать стаб, который к тестируемому коду вообще отношения не имеет. А вдруг там в конструкторе что-то поменяется и данные он будет тянуть не с БД, а с АПИ. И потом тест упадет, из-за неправильных стабов. То есть тут как ни крути, а они «хрупкие». И даже если соблюдать правильность соглашений при вызове метода, хрупкость получится из-за стабов.
Есть существенное ограничение на статические методы. Впринципе, его можно обойти, если гонять тесты в разных процессах, но в том же PHPUnit оно присутствует.
Кстати, вот хотел спросить о вашем опыте в PHPUnit. Насколько оправдано использование рефлексии для проверки или подстановки разных значений? Вот не могу понять, это хорошая практика, или плохая. С одной стороны, мы с помощью рефлексии можем подставить и подсмотреть нужные значения в класс не дергая его другие методы, и значит, тестировать только один метод. С другой — мы таким образом можем тестировать «коня в вакууме», метод работает, но совершенно не с тем API, с которым используется в коде.
Честно, я не вижу никакого смысла вручную делать то, что обычно делается или денвером автоматически, или уже настроено на хостингах. Курс по системному администрированию будет в другом семестре )
И компоненты, как ни крути, выпиливать приходилось из общего ядра.
Он был монолитным, но это было даже хорошо ) Каркас приложения не приходилось строить из кубиков.
Если сможете сравнить их в статье, буду крайне благодарен )
Вон уже 8ой друпал будет их использовать. В чем там монолитность пока непонятно. ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Вообщем, у меня есть некоторое разочарование. Я надеялся, что в Зенде будут какие-то новые оригинальные архитектурные решения. А их нет (
Если есть догма «хэлперы для повторного использования» то не верьте ей. Используйте их там где это необходимо. Переносить логику в шаблоны необходимости нет. Точно так же, как сейчас не принято писать яваскрипт в шаблонах, или пардон, SQL-запросы, точно так же, следует выводить любую логику за рамки html-кода. Если так не делать, до говнокода останется всего полшага.
Та нет же, любые вычисления — это уже не представление. Их нужно выносить в хэлперы.
Откуда они там возьмутся? Только из циклов. Вообщем, локальных переменных стоит избегать.
Вы не заметили, что Симфони2 уже далеко не монолит, а тоже набор компонентов, и наверное, даже более независимых. Посмотрите немного на Symfony2, и на Symfony Components.
Проблема в том, что в Симфони под единым названием существут 2 разных фреймворка и не все ещё это знают.
Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
А вообще, фигли, Новый Год. Вдруг Дедушка Мороз придет и сделает Хабр таким, как его хотят видеть прилежные детишки с положительной кармой )
Для новостей, гаджетов, и пр. лимит в +10 кармы оправдан. А вот для остального — нужно смотреть и разбираться.