Unit-тестирование в Codeception

[@ainu]

>seeMethodInvoked
Правильно понимаю, что через xdebug отслеживается?

[@ainu]

или debug_backtrace?

[@Davert]

Нет. Гораздо меньше магии )
Хотя идея хороша, подумаю о ней.

[@Davert]

Отвечу более полно: всё дело в том, что мы пишем сценарий. И выполняется он только когда уже написан полностью. А значит метод execute при выполнении может проследить кто и что проверяет после него, и создать моки. Как я говорил, моки обычные, из PHPUnit. В документации много времени посвящено как писать тесты в условиях такой вот парадигмы. Но вот мне показалось, что этот «баг» можно красиво превратить в «фичу» и сейчас понимаю, что она достаточно удобна.

[@plandem]

можно ли как-то безболезненно «отвязать» от Symphony и привязать к другому фреймворку?! очень хотелось бы такую штуку на Yii, например

[@Davert]

А я как бы тут ни разу про Symfony и не упоминал )

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

[@VolCh]

it will render page 404 for unexistent user это же произвольная строка, служащая по сути лишь для документирования?

И ещё вопрос: в codecept run [acceptance|functional] acceptance/functional — это «термины» Codecept или просто названия каталогов? Просто сейчас интересуют интеграционные тесты прежде всего (например, что при вызове функции/метода в базу что-то запишется), но хотелось бы их отделить от будущих юнит и приемочных. От первых из-за скорости, от вторых из-за разной природы. То есть, грубо говоря, интеграционные — это те же юнит, но в которых не всё мокится/стабится. П крайней мере я так привык с PHPUnit :)

P.S. Может заменить в вызовах executeTestedMethodOn($controller, 1) и executeTestedMethodOn($controller, 0) 1 и 0 на константы/переменные? А то несколько минут не мог понять для чего они (переработал с $this->at($index) в PHPUnit :) )

[@Davert]

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 на константы/переменные?

Тоже правильная идея :) Спасибо.

[@artificial]

Как заставить работать Unit тесты с symfony 1.4?

[@Davert]

Нужно как минимум инициализировать автолоадер symfony, ну или само приложение.

В файле tests/unit/_bootstrap.php добавим такие строчки. По крайней мере так это работает у меня.

require_once(dirname(__FILE__).'/../../config/ProjectConfiguration.class.php');
sfProjectConfiguration::getApplicationConfiguration('frontend','test', true);

Теперь классы symfony доступны в тестах.

[@artificial]

Да, спасибо, уже сделал. Но после вот такие вот дела:
Couldn't (CommentCest.php:CommentCest::setNameAndSave)
ErrorException: ob_end_clean(): failed to delete buffer. No buffer to delete
FAILURES!
Tests: 1, Assertions: 0, Errors: 1.
session_start(): Cannot send session cookie — headers already sent

[@Davert]

Скорее всего, нужно обновить версию. Последняя 1.0.2:

codeception.com/02-05-2012/minor-release-1-0-2.html

[@artificial]

Только сегодня последнюю и поставил через PEAR.

[@artificial]

Упс, надо было ENV test поставить, теперь все ок :)

[@Lebnik]

Ребята, если вам нужны только unit-тесты, то мой вам совет: не используйте Codeception, т.к. он сильно ограничивает phpunit и как пример: вы просто не сможете воспользоваться phpunit.xml настройками, который описаны в документации к phpunit, еще пример: Codeception использует свой хендлер ошибок, полностью перекрывая PHPUnit_Util_ErrorHandler::handleError, и кроме как хака перекрывающего хендлер обратно, это Вы никак не решите. И таких случаев очень много. В настоящий момент, когда у меня в проекте уже естьCodeception, я не понимаю, зачем Codeception мне нужен для unit-тестов, и найти список плюсов, я увы нигде найти не смог.

[@Davert]

вообще этот пост дико устарел, сейчас этого функционала просто нет.

"если вам нужны только юнит тесты" — это ключевая фраза. Соглаесн, для юнит-тестов ничего нового не придумаешь. Для небольших библиотек я тоже использую PHPUnit. А вот для всего остального скорее всего понадобятся ещё функциональные, интеграционные и другие тесты. И ковыряя всё это но PHPUnit'е быстро можно натворить херни.

[@alekciy]

А какой есть вместо него?
P.S. Просто в Яндексе по запросу "codeception stub" ссылка на эту статью на 3 позиции.

[@Davert]

На самом деле за этот год у нас прибваилось много фич и в том числе для юнит тестов. Я бы советовал смотреть в нашу доку https://codeception.com/docs/05-UnitTests

А вот полная документация по Stub https://codeception.com/docs/05-UnitTests#Test-Doubles