Comments 18
>seeMethodInvoked
Правильно понимаю, что через xdebug отслеживается?
Правильно понимаю, что через xdebug отслеживается?
или debug_backtrace?
Нет. Гораздо меньше магии )
Хотя идея хороша, подумаю о ней.
Хотя идея хороша, подумаю о ней.
Отвечу более полно: всё дело в том, что мы пишем сценарий. И выполняется он только когда уже написан полностью. А значит метод execute при выполнении может проследить кто и что проверяет после него, и создать моки. Как я говорил, моки обычные, из PHPUnit. В документации много времени посвящено как писать тесты в условиях такой вот парадигмы. Но вот мне показалось, что этот «баг» можно красиво превратить в «фичу» и сейчас понимаю, что она достаточно удобна.
можно ли как-то безболезненно «отвязать» от Symphony и привязать к другому фреймворку?! очень хотелось бы такую штуку на Yii, например
А я как бы тут ни разу про Symfony и не упоминал )
Для юнит-тестов можете использовать хоть сейчас. Для функциональных — нужно написать интеграцию. Это как раз несложно, но мне нужно работающее приложение на Yii, на котором можно тестировать, и человек для консультаций. Вообщем, постучитесь в скайп davert.ua, если интересно разработать эту тему.
Для юнит-тестов можете использовать хоть сейчас. Для функциональных — нужно написать интеграцию. Это как раз несложно, но мне нужно работающее приложение на Yii, на котором можно тестировать, и человек для консультаций. Вообщем, постучитесь в скайп davert.ua, если интересно разработать эту тему.
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 :) )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 на константы/переменные?
Тоже правильная идея :) Спасибо.
Как заставить работать Unit тесты с symfony 1.4?
Нужно как минимум инициализировать автолоадер symfony, ну или само приложение.
В файле tests/unit/_bootstrap.php добавим такие строчки. По крайней мере так это работает у меня.
Теперь классы symfony доступны в тестах.
В файле tests/unit/_bootstrap.php добавим такие строчки. По крайней мере так это работает у меня.
require_once(dirname(__FILE__).'/../../config/ProjectConfiguration.class.php');
sfProjectConfiguration::getApplicationConfiguration('frontend','test', true);
Теперь классы symfony доступны в тестах.
Да, спасибо, уже сделал. Но после вот такие вот дела:
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
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
Скорее всего, нужно обновить версию. Последняя 1.0.2:
codeception.com/02-05-2012/minor-release-1-0-2.html
codeception.com/02-05-2012/minor-release-1-0-2.html
Ребята, если вам нужны только unit-тесты, то мой вам совет: не используйте Codeception, т.к. он сильно ограничивает phpunit и как пример: вы просто не сможете воспользоваться phpunit.xml настройками, который описаны в документации к phpunit, еще пример: Codeception использует свой хендлер ошибок, полностью перекрывая PHPUnit_Util_ErrorHandler::handleError, и кроме как хака перекрывающего хендлер обратно, это Вы никак не решите. И таких случаев очень много. В настоящий момент, когда у меня в проекте уже естьCodeception, я не понимаю, зачем Codeception мне нужен для unit-тестов, и найти список плюсов, я увы нигде найти не смог.
вообще этот пост дико устарел, сейчас этого функционала просто нет.
"если вам нужны только юнит тесты" — это ключевая фраза. Соглаесн, для юнит-тестов ничего нового не придумаешь. Для небольших библиотек я тоже использую PHPUnit. А вот для всего остального скорее всего понадобятся ещё функциональные, интеграционные и другие тесты. И ковыряя всё это но PHPUnit'е быстро можно натворить херни.
А какой есть вместо него?
P.S. Просто в Яндексе по запросу "codeception stub" ссылка на эту статью на 3 позиции.
P.S. Просто в Яндексе по запросу "codeception stub" ссылка на эту статью на 3 позиции.
На самом деле за этот год у нас прибваилось много фич и в том числе для юнит тестов. Я бы советовал смотреть в нашу доку https://codeception.com/docs/05-UnitTests
А вот полная документация по Stub https://codeception.com/docs/05-UnitTests#Test-Doubles
Sign up to leave a comment.
Unit-тестирование в Codeception