Комментарии 33
Честно говоря, я сначала глазам не поверил… Описание тестов на русском языке! Переспросил у автора: да, это действительно не шутка. И хотя пока еще одолевают двойственные чувства, но это блин, как минимум приятно!
+1
В догонку вам: www.knplabs.com/en/blog/behat-2.0 :-)
+1
Разве PHPUnit не для написания модульных тестов предназначен? Зачем на нем функциональные тесты писать?
0
Nope, dude! He's right: github.com/sebastianbergmann/phpunit/commit/6aa9183496f9bb2131d17ba08195a93a07937762#comments ;-)
0
Не совсем понял, выпиливаются все классы или только возможность гонять тесты из консоли PHPUnit? Почти год прошел, а сам модуль Story существует в том виде в котором был.
Ну такое, просто не бихэтом единым. В свое время хотел перевести рабочий проект на бихет, но понял, что писать тесты на человекоподобном языке ни один наш разработчик не захочет. Да и нужно ли? Слишком много времени будет тратится на отладку, написание правильных конструкций и правку орфографических ошибок. Сейчас использую надстройку над PHPUnit BDD и вроде всё устраивает.
Короче, Behat вещь специфическая, но в свете отсутствия альтернативы подается как единственно правильная.
Ну такое, просто не бихэтом единым. В свое время хотел перевести рабочий проект на бихет, но понял, что писать тесты на человекоподобном языке ни один наш разработчик не захочет. Да и нужно ли? Слишком много времени будет тратится на отладку, написание правильных конструкций и правку орфографических ошибок. Сейчас использую надстройку над PHPUnit BDD и вроде всё устраивает.
Короче, Behat вещь специфическая, но в свете отсутствия альтернативы подается как единственно правильная.
0
«PHPUnit's BDD functionality is deprecated in PHPUnit 3.5 and will be removed in PHPUnit 3.6.»
docs.behat.org/cookbook/behat_and_mink.html
docs.behat.org/cookbook/behat_and_mink.html
0
Не спорю, минк клёвый. Тогда вопрос: насколько сложно архитектурно начать использовать Behat без Gherkin?
0
Вопрос крайне странный. Behat — это и есть Gherkin! Ваша неприязнь к средству еще не говорит о том, что вам нельзя попробовать его использовать, верно? Мне сложно спорить с вашим «не нравится», пока у вас не появится вменяемых причин, а для этого надо хотя бы попытаться.
И по поводу ваших предыдущих тезисов:
1. «Слишком много времени будет тратится на написание правильных конструкций и правку орфографических ошибок» ©
Из коробки:
2. «Слишком много времени будет тратится на отладку» ©
Из коробки:
Вы извините, но я крайне сомневаюсь, что вы сможете на PHPUnit функционально оттестировать вашу страницу настолько же быстро как с Behat (см. выше). И крайне сомневаюсь, что дебаг сценарных тестов в PHPUnit удобнее, чем в Behat (см. выше) ;-)
И по поводу ваших предыдущих тезисов:
1. «Слишком много времени будет тратится на написание правильных конструкций и правку орфографических ошибок» ©
Из коробки:
2. «Слишком много времени будет тратится на отладку» ©
Из коробки:
Вы извините, но я крайне сомневаюсь, что вы сможете на PHPUnit функционально оттестировать вашу страницу настолько же быстро как с Behat (см. выше). И крайне сомневаюсь, что дебаг сценарных тестов в PHPUnit удобнее, чем в Behat (см. выше) ;-)
0
Ну просто у меня есть свое виденье того как лучше описывать сценарии. Например, хотелось бы для описания сценариев использовать тот же PHP, при если именовать функции по тому же принципу, что в bdd, то код остается понятен непрограммистам, но в то же время благодаря автодополнению пишется в разы быстрее обычного текста.
Вроде так
$i->click(3);
$i->click(2);
$i->click('+');
$i->shouldGet(5)
Если заменить Gherkin другим языком сценариев в нельзя то останусь пока на PHPUnit.
Вроде так
$i->click(3);
$i->click(2);
$i->click('+');
$i->shouldGet(5)
Если заменить Gherkin другим языком сценариев в нельзя то останусь пока на PHPUnit.
0
Т.е. заменить Gherkin другим языком описания сценариев никак нельзя?
0
Что вас не устраивает в Gherkin?
0
Ну я же сказал — его человечность :)
Например:
«Допустим я на странице „/app_dev.php/demo/hello/Fabien“»
Грамотный человек поставит после слова «допустим» запятую, а парсер это не схавает. И всё вывалится. Ну это как частный пример.
А суть в том, что для описания хотелось бы использовать более формальный язык, тот же PHP, например. Там большинство ошибок можно исправить на этапе написания, а большинство команд можно написать правильно сразу с помощью автодополнения.
Грубо говоря, смотреть всё время в список regex'ов и выискивать там нужную команду я не хочу.
Например:
«Допустим я на странице „/app_dev.php/demo/hello/Fabien“»
Грамотный человек поставит после слова «допустим» запятую, а парсер это не схавает. И всё вывалится. Ну это как частный пример.
А суть в том, что для описания хотелось бы использовать более формальный язык, тот же PHP, например. Там большинство ошибок можно исправить на этапе написания, а большинство команд можно написать правильно сразу с помощью автодополнения.
Грубо говоря, смотреть всё время в список regex'ов и выискивать там нужную команду я не хочу.
0
У вас коренное непонимание принципов сценарного BDD, откуда явный перекос в спецификации. Почитайте dannorth.net/whats-in-a-story/ на досуге ;-)
0
Да, возможно я имею ввиду что-то среднее между BDD и функциональным тестированием. От первого хочу видеть возможность более явно указывать сценарий, от второго — описание теста на языке программирования.
Просто в моем понимании тесты пишутся программистами, а значит удобнее описывать используя всё богатство инструментариев, которое дает полноценный язык программирования.
Просто в моем понимании тесты пишутся программистами, а значит удобнее описывать используя всё богатство инструментариев, которое дает полноценный язык программирования.
0
Просто почитайте статью.
0
Насколько я понял, тут отличия где-то в том же чем TDD отличается от написания тестов. TDD предусматривает методологию разработки, частью которой является написание тестов. То же и с BDD. Исходя из описания, BDD хорошо подходит, когда описание сценариев это совместный продукт тестера, менеджера, заказчика и программиста. Когда же сценарий пишется самим программистом для себя или «по мотивам» фичи, с целью просто покрыть функционал, то именно методология немного излишня.
Скажу иначе, как программисту мне будет трудно убедить руководство использовать BDD в проекте. Но лаконично писать сценарии для своего функционала я могу и без использования самой методологии. Так же плюсом является возможность показать тестеру какие действия выполняет мой тест и почему, например, тест проходит, а его действия — нет.
Т.е. у меня есть конкретная цель — покрыть проект функциональными тестами с простыми сценариями и понятными описаниями, доступными непрограммистам. Именно по этому мне нравится Behat и BDD вцелом, но тесты должны оставаться тестами, а не частью методологии разработки. За неё я не отвечаю.
Скажу иначе, как программисту мне будет трудно убедить руководство использовать BDD в проекте. Но лаконично писать сценарии для своего функционала я могу и без использования самой методологии. Так же плюсом является возможность показать тестеру какие действия выполняет мой тест и почему, например, тест проходит, а его действия — нет.
Т.е. у меня есть конкретная цель — покрыть проект функциональными тестами с простыми сценариями и понятными описаниями, доступными непрограммистам. Именно по этому мне нравится Behat и BDD вцелом, но тесты должны оставаться тестами, а не частью методологии разработки. За неё я не отвечаю.
0
Вы все правильно поняли.
Behat — тул для BDD разработки. Вы же не используете BDD, вы просто пишете функциональные тесты. Behat без BDD — это как машина без колес, все верно ;-)
Behat — тул для BDD разработки. Вы же не используете BDD, вы просто пишете функциональные тесты. Behat без BDD — это как машина без колес, все верно ;-)
0
Ну вот, в этой хабровской заметке как раз идет речь о том, чтобы использовать Behat для функциональных тестов. Можно было бы изначально сказать, что пример малость не верен.
Потому я и спрашивал, можно ли заменить язык сценариев, чтобы использовать существующую инфраструктуру для написания функциональных тестов, но при этом писать тесты не так, что никто не поймет что там происходит, а в более явном виде.
Потому я и спрашивал, можно ли заменить язык сценариев, чтобы использовать существующую инфраструктуру для написания функциональных тестов, но при этом писать тесты не так, что никто не поймет что там происходит, а в более явном виде.
0
Вы подменяете понятия:
«писать тесты не так, что никто не поймет что там происходит, а в более явном виде»
Сценарии как раз и пишуться для того, чтобы кто угодно понял что там происходит без необходимости понимать как это реализовано ;-)
«писать тесты не так, что никто не поймет что там происходит, а в более явном виде»
Сценарии как раз и пишуться для того, чтобы кто угодно понял что там происходит без необходимости понимать как это реализовано ;-)
0
Да, но не обязательно писать это именно на человеческом языке. Точно так же можно писать на PHP. ПРи этом совершенно не сложно сделать так, чтобы код был понятен обычному человеку. Хотя бы тестеру.
0
Код по определению не может быть понятен обычному человеку. Ну или у нас слишком разняться понятия «обычности».
Если перед вами стоит задача писать простые функциональные — никаких проблем. Пишите хоть на JAVA. Но не называйте это BDD! Когда я говорю «сценарий», я имею в виду «поведенческие сценарии», являющиеся частью методологии, а не то, что называете сценариями вы ;-)
Если перед вами стоит задача писать простые функциональные — никаких проблем. Пишите хоть на JAVA. Но не называйте это BDD! Когда я говорю «сценарий», я имею в виду «поведенческие сценарии», являющиеся частью методологии, а не то, что называете сценариями вы ;-)
0
Ну да, дяде васе с улицы тест понятен не будет, тут согласен. Впрочем, это и не нужно.
Мне, как было сказано, пофиг каким DD это будет называться. Есть сценарии описанные простым языком. В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.
Вроде же разобрались, что я говорю конкретно о функциональных тестах. Модель BDD просто помогает упростить их спецификацию.
Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. Он добавляет новую методологию, а с ней и присущие ей сложности. См. заголовок статьи.
Мне, как было сказано, пофиг каким DD это будет называться. Есть сценарии описанные простым языком. В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.
Вроде же разобрались, что я говорю конкретно о функциональных тестах. Модель BDD просто помогает упростить их спецификацию.
Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. Он добавляет новую методологию, а с ней и присущие ей сложности. См. заголовок статьи.
0
«В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.»
Если подразумевается, что никто кроме программистов этот код читать не будет, зачем эти преобразования?
А если подразумевается обратное, то, извините, но ваши описания никто кроме программиста прочитать все-равно не сможет. С хитрыми преобразованиями или без.
«Модель BDD просто помогает упростить их спецификацию.»
Методология сценарного BDD описывает разработку через поведенческие сценарии. Эти сценарии являются ни чем иным, как приемочным критерем разрабатываемых фич и могут быть использованы в качестве приемочных тестов. Но основная идея — именно в коммуникции со стэк-холдерами, продакт-овнерами, менеджерами и иже с ними.
«Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. „
Изящно заменяет. Если вы итак применяете аджайл и используете что-то вроде scrum или другой историйной методологии — вы УЖЕ пишете пользовательские истории. Behat позволяет эти истории использовать в качестве функциональных тестов. Были юзер-стори, остались юзер-стори. Только теперь они исполняемы!
Если вы ватерфолите и не в зуб ногой что такое гибкая разработка, тогда да. Вам будет казаться, что Behat требует излишней дополнительной работы и вам это все не нужно.
Если подразумевается, что никто кроме программистов этот код читать не будет, зачем эти преобразования?
А если подразумевается обратное, то, извините, но ваши описания никто кроме программиста прочитать все-равно не сможет. С хитрыми преобразованиями или без.
«Модель BDD просто помогает упростить их спецификацию.»
Методология сценарного BDD описывает разработку через поведенческие сценарии. Эти сценарии являются ни чем иным, как приемочным критерем разрабатываемых фич и могут быть использованы в качестве приемочных тестов. Но основная идея — именно в коммуникции со стэк-холдерами, продакт-овнерами, менеджерами и иже с ними.
«Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. „
Изящно заменяет. Если вы итак применяете аджайл и используете что-то вроде scrum или другой историйной методологии — вы УЖЕ пишете пользовательские истории. Behat позволяет эти истории использовать в качестве функциональных тестов. Были юзер-стори, остались юзер-стори. Только теперь они исполняемы!
Если вы ватерфолите и не в зуб ногой что такое гибкая разработка, тогда да. Вам будет казаться, что Behat требует излишней дополнительной работы и вам это все не нужно.
0
Ох ты ж йо. При чем тут методология? Мы же вроде от неё абстрагировались.
Вернемся к простому.
Я пишу тест, он проходит.
Тестер тестирует фичу, она не срабатывает.
Я показываю ему тест, он его понимает и говорит, что то ли он не те данные вводил, то ли выполнял не те команды.
После того как мы с тестером согласны, что сценарий напиан правильно и у него он срабатывает, фича считается работающей и проверяется на каждой итерации тестирования.
Вот и всё что я хочу. Behat не нужен мне в плане методологии. Я ею не занимаюсь. А вот тестами и коммуникацией с тестировщиком и менеджером — постоянно.
Вернемся к простому.
Я пишу тест, он проходит.
Тестер тестирует фичу, она не срабатывает.
Я показываю ему тест, он его понимает и говорит, что то ли он не те данные вводил, то ли выполнял не те команды.
После того как мы с тестером согласны, что сценарий напиан правильно и у него он срабатывает, фича считается работающей и проверяется на каждой итерации тестирования.
Вот и всё что я хочу. Behat не нужен мне в плане методологии. Я ею не занимаюсь. А вот тестами и коммуникацией с тестировщиком и менеджером — постоянно.
0
Да, и кстати конкретно в этой хабровской заметке Behat подается как альтернатива функциональному тестированию. О похожей альтернативе я и говорю. Она не требует соблюдения всех формальностей описания Story.
0
Я вообще имел в виду, что для написания функциональных тестов использовать xUnit не самое разумное решение и есть специализированные инструменты. Все остальное ниже за меня написали :)
0
Behat — альтернатива не функциональному тестированию, а альтернатива функциональному тестированию через PHPUnit. Ну и конечно же один из способов BDD разработки.
0
Лучше для функционального тестирования использовать специализированные инструменты, мне кажется, например, selenium или selenium rc. Хотя, функциональные тесты на, например, XML-API мы тоже пишем на xUnit.
0
Причем с помощью прокси можно тестить на разных операционых системах и в разных броузерах.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Установка и настройка функционального тестирования в Symfony2 с помощью Behat и Mink