Какой бы ты ни был специалист, а больше чем начальнику не заплатят. Такие дела. А то, что начальники выбираются по географическому, а не профессиональному принципу, никому не секрет.
Кроме того, что новость второй свежести, так и автор явно сам далеко не в теме. Ну а также вряд ли знаком с тем, что на Хабре нет модераторов. Советую топик быстро спрятать от греха подальше.
it will render page 404 for unexistent user это же произвольная строка, служащая по сути лишь для документирования?
Да, комментарий, введенный в код, чисто затем чтобы неочевидные варианты поведения стоит дополнительно описывать.
но хотелось бы их отделить от будущих юнит и приемочных
Да, собственно, потому изначально делается 3 тестовых сьюиты. Каждая из сьюит это конфигурационный файл в папке tests + каталог там же. Если 3х окажется мало, сделайте себе integration:
— скопируйте конфиг unit.suite.yml > integration.suite.yml
— создайте папку tests/integration
— и важно не забыть в integration.suite.yml — указать нового «парня», т.е. Guy-class, например, InterGuy.
— подключить модули и выполнить 'codecept build'.
Впринципе очень даже спасибо за вопрос, как раз создание своих сьюит пока плохо освещено в документации.
Может заменить в вызовах executeTestedMethodOn($controller, 1) и executeTestedMethodOn($controller, 0) 1 и 0 на константы/переменные?
А я как бы тут ни разу про Symfony и не упоминал )
Для юнит-тестов можете использовать хоть сейчас. Для функциональных — нужно написать интеграцию. Это как раз несложно, но мне нужно работающее приложение на Yii, на котором можно тестировать, и человек для консультаций. Вообщем, постучитесь в скайп davert.ua, если интересно разработать эту тему.
Отвечу более полно: всё дело в том, что мы пишем сценарий. И выполняется он только когда уже написан полностью. А значит метод execute при выполнении может проследить кто и что проверяет после него, и создать моки. Как я говорил, моки обычные, из PHPUnit. В документации много времени посвящено как писать тесты в условиях такой вот парадигмы. Но вот мне показалось, что этот «баг» можно красиво превратить в «фичу» и сейчас понимаю, что она достаточно удобна.
Кстати, вспомним историю того же Demonoid, которые поступили весьма красиво. Сейчас, если не ощибаюсь, они висят в Украине на Коллоколе, но для Украины закрыты. В итоге они висят в полном офшоре. Красота.
Можно только сказать, что гонорары в Голливуде малость перегреты. И если актеры/режиссеры/сценаристы будут получать не миллионы с каждого фильма, а просто хорошие деньги, то это если не убьет голливуд, то по крайней мере сделает его менее жадным.
Это б звучало утопически, если бы не сериалы. 20-40-минутные фильмы вытесняют многомиллионные полнометражные картины. С малоизвестными актерами. Без грандиозной рекламной поддержки. Без цели собрать миллионы по весму миру…
Давайте будем объективны. Это привычка. За 8 лет, а начинали вы явно с РНР4 она закрепилась. Сейчас она ничем не обусловлена. Я не против соблюдения старых стандартов. В исходниках многих проектов всё ещё есть эти черточки, в той же Doctrine2. Но навязывать их смысла нет.
Да вы что, PEAR это такой дедушка-ветеран больной радикулитом, вечно краяхтящий и ноющий. В PEAR ещё слишком много библиотек с PHP4. На дворе уже 5.4, а им нужно поддерживать свой стандарт, для соблюдения стиля, который давно должен был бы стать deprecated.
С тех пор как в PHP появился полноценный ООП, все эти _ стали просто неуместными.
Ну опять таки, это не помогает, а только мешает коду. Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property…
Другой пример. Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
В файле tests/unit/_bootstrap.php добавим такие строчки. По крайней мере так это работает у меня.
Теперь классы symfony доступны в тестах.
Да, комментарий, введенный в код, чисто затем чтобы неочевидные варианты поведения стоит дополнительно описывать.
Да, собственно, потому изначально делается 3 тестовых сьюиты. Каждая из сьюит это конфигурационный файл в папке tests + каталог там же. Если 3х окажется мало, сделайте себе integration:
— скопируйте конфиг unit.suite.yml > integration.suite.yml
— создайте папку tests/integration
— и важно не забыть в integration.suite.yml — указать нового «парня», т.е. Guy-class, например, InterGuy.
— подключить модули и выполнить 'codecept build'.
Впринципе очень даже спасибо за вопрос, как раз создание своих сьюит пока плохо освещено в документации.
Тоже правильная идея :) Спасибо.
Для юнит-тестов можете использовать хоть сейчас. Для функциональных — нужно написать интеграцию. Это как раз несложно, но мне нужно работающее приложение на Yii, на котором можно тестировать, и человек для консультаций. Вообщем, постучитесь в скайп davert.ua, если интересно разработать эту тему.
Хотя идея хороша, подумаю о ней.
Я так подозреваю, вы приемочный тест писали? Вечером посмотрю в чем проблема.
Это б звучало утопически, если бы не сериалы. 20-40-минутные фильмы вытесняют многомиллионные полнометражные картины. С малоизвестными актерами. Без грандиозной рекламной поддержки. Без цели собрать миллионы по весму миру…
С тех пор как в PHP появился полноценный ООП, все эти _ стали просто неуместными.
Ну опять таки, это не помогает, а только мешает коду. Например, очень хорошо получается, если в классе есть два свойства, одно: $this->_property, а другое $this->property…
Другой пример. Набираешь в IDE $this->property, не находишь свойства, ругаешься, лезешь в исходники и находишь, что оно на самом деле _property. Ну и зачем такие подставы делать?
Третее. Любое изменение публичности доступа ведет то ли к рефакторингу то ли к mass-replace.
А в четвертых: зачем?
$this->post = Post::find($this->_post);