У меня к сожалению не завелось.
1. Прочитал доки по установке на Вашем сайте.
2. Установил пакет из pear.
3. Запустил codecept install через sudo
Все дальнейшие команды (codecept bootstrap, codecept buil, codecept run) не дают никаких результатов ни в пустой папке, ни в папке с каким либо проектом. Вообще команда codecept никак не реагирует ни на какие параметры, даже если ей передать произвольную строку.
ой. Старая версия PEAR Installer. Что не обходимо установить в виде pear пакетов: Mink и Symfony Components.
Я постараюсь по-быстрому добавить возможность установки через Composer.
А по теме. Спасибо за работу. Единственный минус BDT, что покрыть все use case просто невозможно. Т.е. нет никакой гарантии что оно действительно работает.
Ой, я только недавно под symfony2 оформил. Что поделаешь — мало с ним работаю :( Но кстати, важно не то, что Symfony2 завелся, а то, что через BrowserKit есть универсальный доступ практически ко всем фреймворкам.
Ну тут скорее дело привычки. И то и то сценарный BDD, но мне проще писать PHP-код, а не сочинения на тему «каким я вижу сайт».
Ну а из принципиальных, behat занимается только приемочными тестами. Тут же вся инфраструктура, с модулями для чистки БД. Ну и наверняка, много отличий в мелочах. Например, Codeception автоматически сохраняет скриншот последней страницы, если тест не удался. Ну, или умеет эмулировать AJAX-запросы в режиме PHP-браузера. Все команды понимают как названия, так и CSS-селекторы…
Не-не-не, на RubyC была отличная презенташка, где рассказывалось, что BDD это Beer Driven Development. Так что, в такой вот расшифровке, оно очень даже верно.
А вообще, я использую термин, BDD не потому что он там уместен, а потому что так проще донести мысль. Может он и некорректен, но судя по всему, как ни крути, народ всё равно будет сравнивать с Behat.
Это 2 разные вещи. У автора — высокоуровневый тул для функционального тестирования. Behat — тул для тестирования бизнесс правил, описанных в виде поведенческих сценариев на языке, доступном для «непрограммистов».
Корректнее сравнивать этот тул с PHPUnit/PHPSpec+Mink, потому как он имеет больше общего с функциональными спецификациями (Spec BDD, Unit tests), нежели поведенческими сценариями (Scenario BDD).
Ок, а как его прикрутить к continuous integration server (Jenkins, Hudson и иже с ними)? Если оно пользует PHPUnit (скорее всего его части asserts и профайлинга тестов) — как заставить его писать отчёты по покрытию тестами и т.д. в файлики?
Насчет отчетов по покрытию тестами, я не совсем понял. Вы имеете ввиду, CodeCoverage? Если мы говорим о функциональных тестах, то они никогда не покроют код. А приемочные его даже дергать не будут.
Из того что есть: генерация отчетов в виде HTML и в виде репортов.
Если уж решили взяться за написание тестов «человеческим языком», то почему бы не использовать Gherkin? Это, на мой взгляд, горяздо более наглядный и гибкий способ описания сценариев.
А зачем нам ещё один Behat? ;)
Читаемый код это тоже человеческий язык. Хороший код читается без комментариев, а пишется быстрее текста. Например, через указанное автодополнение.
Хотя смотря, конечно, кто будет читать ваши тесты. Если их будут читать разработчики + менеджеры, то Codeception они осилят (плюс можно перевести текст в нормальный english), если текст будут читать заказчики, то, конечно Behat лучше.
Каждый тест можно ещё в таком виде представить:
I WANT TO SIGN IN
I am on page '/login'
I fill field ['signin[username]', 'davert']
I fill field ['signin[password]', 'qwerty']
I click 'LOGIN'
I see 'Welcome, Davert!'
Неужели это от того, что PHP-разработчики поголовно быдло-кодеры? Я считаю, что нет.
Вы так говорите, будто согласны с тем что PHP-разработчики быдло кодеры, но не согласны что из-за этого приложения не тестируют.
Они не тестируют, ибо нет хороших простых инструментов:
Что есть? «PHPUnit + Selenium». Буду ли я стрелять из пушки по воробьям, если, допустим, у меня небольшой сайт на друпале и мне совершенно не хочется заморачиваться в установке этих двух монстров. Человеку не привычному к PHPUnit настройка этой связки может трудной, а в итоге напрочь отобьет желание что-то тестировать. А самое глваное — нет необходимости гонять все тесты в Selenium.
Тот же Behat+Mink намного лучше, но он, как мне кажется, всё равно пока больше для гиков.
В том же Ruby (on Rails), как выше уже написали, существует прекрасная связка Cucumber+Capybara+RSpec. и к оным существует over 9000 разнообразных примочек, чтобы жизнь тестера была похожа на сказку. В свое время, когда еще приходилось немного кодить на php, я был дико обрадован появлению Behat, т.к. уже тогда слабо себе представлял разработку без автоматизированного тестирования.
Опять таки, комментарий выше. Если тестировать с Goutte или в Selenium, оно обязательно заработает. Ну а список поддерживаемых фреймворков будет постепенно обновляться.
Решил поиграть с codeception, но заметил интересную зависимость. Если передать в метод see() метку с национальными символами в utf-8, то всё работает правильно до момента пока вторым параметром не указать селектор области поиска.
Пример:
$I->see('Москва');
> * I see «Москва»
> OK
$I->see('Москва', 'div');
> 1. I see ["\u041c\u043e\u0441\u043a\u0432\u0430",«div»]
>
>FAILURES!
Не поверите, недавно как раз добавил модули для REST и SOAP тестирования.
Пока правда нету развернутых гайдов по их использованию, но уже достаточно документированы.
Не могу найти инфу на тему как лучше сделать отдельный конфиг для теста / группы тестов.
Можно конечно инклудить свой, но красивше было бы заюзать системный yml конфиг
Не подскажете как доставать значения из yml в пространство теста?
PS: использую только приемочные для тестирования REST сервисов
Codeception — тестирование по-новому