Ну вот, в этой хабровской заметке как раз идет речь о том, чтобы использовать Behat для функциональных тестов. Можно было бы изначально сказать, что пример малость не верен.
Потому я и спрашивал, можно ли заменить язык сценариев, чтобы использовать существующую инфраструктуру для написания функциональных тестов, но при этом писать тесты не так, что никто не поймет что там происходит, а в более явном виде.
Да, и кстати конкретно в этой хабровской заметке Behat подается как альтернатива функциональному тестированию. О похожей альтернативе я и говорю. Она не требует соблюдения всех формальностей описания Story.
Насколько я понял, тут отличия где-то в том же чем TDD отличается от написания тестов. TDD предусматривает методологию разработки, частью которой является написание тестов. То же и с BDD. Исходя из описания, BDD хорошо подходит, когда описание сценариев это совместный продукт тестера, менеджера, заказчика и программиста. Когда же сценарий пишется самим программистом для себя или «по мотивам» фичи, с целью просто покрыть функционал, то именно методология немного излишня.
Скажу иначе, как программисту мне будет трудно убедить руководство использовать BDD в проекте. Но лаконично писать сценарии для своего функционала я могу и без использования самой методологии. Так же плюсом является возможность показать тестеру какие действия выполняет мой тест и почему, например, тест проходит, а его действия — нет.
Т.е. у меня есть конкретная цель — покрыть проект функциональными тестами с простыми сценариями и понятными описаниями, доступными непрограммистам. Именно по этому мне нравится Behat и BDD вцелом, но тесты должны оставаться тестами, а не частью методологии разработки. За неё я не отвечаю.
Да, возможно я имею ввиду что-то среднее между BDD и функциональным тестированием. От первого хочу видеть возможность более явно указывать сценарий, от второго — описание теста на языке программирования.
Просто в моем понимании тесты пишутся программистами, а значит удобнее описывать используя всё богатство инструментариев, которое дает полноценный язык программирования.
«Допустим я на странице „/app_dev.php/demo/hello/Fabien“»
Грамотный человек поставит после слова «допустим» запятую, а парсер это не схавает. И всё вывалится. Ну это как частный пример.
А суть в том, что для описания хотелось бы использовать более формальный язык, тот же PHP, например. Там большинство ошибок можно исправить на этапе написания, а большинство команд можно написать правильно сразу с помощью автодополнения.
Грубо говоря, смотреть всё время в список regex'ов и выискивать там нужную команду я не хочу.
Ну просто у меня есть свое виденье того как лучше описывать сценарии. Например, хотелось бы для описания сценариев использовать тот же PHP, при если именовать функции по тому же принципу, что в bdd, то код остается понятен непрограммистам, но в то же время благодаря автодополнению пишется в разы быстрее обычного текста.
Вроде так
$i->click(3);
$i->click(2);
$i->click('+');
$i->shouldGet(5)
Если заменить Gherkin другим языком сценариев в нельзя то останусь пока на PHPUnit.
Не совсем понял, выпиливаются все классы или только возможность гонять тесты из консоли PHPUnit? Почти год прошел, а сам модуль Story существует в том виде в котором был.
Ну такое, просто не бихэтом единым. В свое время хотел перевести рабочий проект на бихет, но понял, что писать тесты на человекоподобном языке ни один наш разработчик не захочет. Да и нужно ли? Слишком много времени будет тратится на отладку, написание правильных конструкций и правку орфографических ошибок. Сейчас использую надстройку над PHPUnit BDD и вроде всё устраивает.
Короче, Behat вещь специфическая, но в свете отсутствия альтернативы подается как единственно правильная.
Второй уже обзор юзабилити за сегодня, но этот адекватностью не блещет. Взбесило замечение про логотип Хабра, автор наверное и понятия не имеет о том, что такое юзабилити. Если кто-то привык к тому, что логотип в любых ситуациях ведет себя одинаково — показывает актуальную главную страницу, значит так кому-то удобно, почему вдруг это плохо с точки зрения юзабилити, автор даже не пытается аргументировать.
Короче, читайте предыдущий обзор от вебпрофессионалов. Там поболее адекватных мыслей будет.
Насчет Open Source, вы не поучвствовали противоречия? Он говорит о том, что главным кртерием явлется инновационность, но везде сразу добавляет — коммерциализация. Эти слова идут всегда в паре, одно за другим, как две стороны медали. Одна красивая, а другая полезная. Так вот, не показалось ли, что коммерциализация и опенсорс это как-то немного противоречивые понятия? Я конечно, понимаю, что разработчики могут предлагать бизнес-решения на оснве опенсорсных, но во главу угла ставится именно коммерциализация. Так что говоря об опенсорсе, скорее всего пытаются съехать с темы и налить воды.
Ну его мессенджер мне уже и не нужен. Всех друзей охватывает аська + скайп + вконтакт. А принципиальных отличий вконтакта от фейсбука, лично я не вижу.
Не понимаю, чего все тролят автора. Его мнение достаточно логичное, оно аргументировано, имеет право на существование. Единственное, что разделяет приавтность и неприватность данных, это то же, что разделяет неуловимого Джо и обычного Джо. Неуловимый Джо никому не нужен, так и чужие данные приватны пока они никому нафиг не нужны. Пользователи могут только передвигать барьер приватности от закрытости к полной публичности. И разговор идет как раз о том, чтобы дать возможность максимально (а не полностью) сохранять свою информаицю тайной.
И никто не говорит, что обязательно при этом нужно покинуть всю свою социальную жизнь. Но дайте возможности контролировать её и удалять те вещи, которые номинально и не являются публичными. Фотографии, на вконтакте не стираются, нельзя запретить друзьям себя отмечать, и т.д. — это нарушение прав. С другой стороны, пока за Гуглом ничего плохого не вижу, даже очень на него надеюсь. Может это будет первая полезная для меня социалка. Увы, контакт, полезен мне сейчас только как интернет мессенджер.
Потому я и спрашивал, можно ли заменить язык сценариев, чтобы использовать существующую инфраструктуру для написания функциональных тестов, но при этом писать тесты не так, что никто не поймет что там происходит, а в более явном виде.
Скажу иначе, как программисту мне будет трудно убедить руководство использовать BDD в проекте. Но лаконично писать сценарии для своего функционала я могу и без использования самой методологии. Так же плюсом является возможность показать тестеру какие действия выполняет мой тест и почему, например, тест проходит, а его действия — нет.
Т.е. у меня есть конкретная цель — покрыть проект функциональными тестами с простыми сценариями и понятными описаниями, доступными непрограммистам. Именно по этому мне нравится Behat и BDD вцелом, но тесты должны оставаться тестами, а не частью методологии разработки. За неё я не отвечаю.
Просто в моем понимании тесты пишутся программистами, а значит удобнее описывать используя всё богатство инструментариев, которое дает полноценный язык программирования.
Например:
«Допустим я на странице „/app_dev.php/demo/hello/Fabien“»
Грамотный человек поставит после слова «допустим» запятую, а парсер это не схавает. И всё вывалится. Ну это как частный пример.
А суть в том, что для описания хотелось бы использовать более формальный язык, тот же PHP, например. Там большинство ошибок можно исправить на этапе написания, а большинство команд можно написать правильно сразу с помощью автодополнения.
Грубо говоря, смотреть всё время в список regex'ов и выискивать там нужную команду я не хочу.
Вроде так
$i->click(3);
$i->click(2);
$i->click('+');
$i->shouldGet(5)
Если заменить Gherkin другим языком сценариев в нельзя то останусь пока на PHPUnit.
Ну такое, просто не бихэтом единым. В свое время хотел перевести рабочий проект на бихет, но понял, что писать тесты на человекоподобном языке ни один наш разработчик не захочет. Да и нужно ли? Слишком много времени будет тратится на отладку, написание правильных конструкций и правку орфографических ошибок. Сейчас использую надстройку над PHPUnit BDD и вроде всё устраивает.
Короче, Behat вещь специфическая, но в свете отсутствия альтернативы подается как единственно правильная.
www.phpunit.de/manual/current/en/behaviour-driven-development.html
Короче, читайте предыдущий обзор от вебпрофессионалов. Там поболее адекватных мыслей будет.
то пожалуйста
davert@lestrostudio.com
Спасибо
И никто не говорит, что обязательно при этом нужно покинуть всю свою социальную жизнь. Но дайте возможности контролировать её и удалять те вещи, которые номинально и не являются публичными. Фотографии, на вконтакте не стираются, нельзя запретить друзьям себя отмечать, и т.д. — это нарушение прав. С другой стороны, пока за Гуглом ничего плохого не вижу, даже очень на него надеюсь. Может это будет первая полезная для меня социалка. Увы, контакт, полезен мне сейчас только как интернет мессенджер.