Pull to refresh

Comments 33

Честно говоря, я сначала глазам не поверил… Описание тестов на русском языке! Переспросил у автора: да, это действительно не шутка. И хотя пока еще одолевают двойственные чувства, но это блин, как минимум приятно!
Внутри просто регекспы, больше никакой магии.
Разве PHPUnit не для написания модульных тестов предназначен? Зачем на нем функциональные тесты писать?
Не совсем понял, выпиливаются все классы или только возможность гонять тесты из консоли PHPUnit? Почти год прошел, а сам модуль Story существует в том виде в котором был.

Ну такое, просто не бихэтом единым. В свое время хотел перевести рабочий проект на бихет, но понял, что писать тесты на человекоподобном языке ни один наш разработчик не захочет. Да и нужно ли? Слишком много времени будет тратится на отладку, написание правильных конструкций и правку орфографических ошибок. Сейчас использую надстройку над PHPUnit BDD и вроде всё устраивает.

Короче, Behat вещь специфическая, но в свете отсутствия альтернативы подается как единственно правильная.
Не спорю, минк клёвый. Тогда вопрос: насколько сложно архитектурно начать использовать Behat без Gherkin?
Вопрос крайне странный. Behat — это и есть Gherkin! Ваша неприязнь к средству еще не говорит о том, что вам нельзя попробовать его использовать, верно? Мне сложно спорить с вашим «не нравится», пока у вас не появится вменяемых причин, а для этого надо хотя бы попытаться.

И по поводу ваших предыдущих тезисов:

1. «Слишком много времени будет тратится на написание правильных конструкций и правку орфографических ошибок» ©
Из коробки:
image
2. «Слишком много времени будет тратится на отладку» ©
Из коробки:
image

Вы извините, но я крайне сомневаюсь, что вы сможете на PHPUnit функционально оттестировать вашу страницу настолько же быстро как с Behat (см. выше). И крайне сомневаюсь, что дебаг сценарных тестов в PHPUnit удобнее, чем в Behat (см. выше) ;-)
Ну просто у меня есть свое виденье того как лучше описывать сценарии. Например, хотелось бы для описания сценариев использовать тот же PHP, при если именовать функции по тому же принципу, что в bdd, то код остается понятен непрограммистам, но в то же время благодаря автодополнению пишется в разы быстрее обычного текста.

Вроде так
$i->click(3);
$i->click(2);
$i->click('+');
$i->shouldGet(5)

Если заменить Gherkin другим языком сценариев в нельзя то останусь пока на PHPUnit.
Т.е. заменить Gherkin другим языком описания сценариев никак нельзя?
Что вас не устраивает в Gherkin?
Ну я же сказал — его человечность :)
Например:

«Допустим я на странице „/app_dev.php/demo/hello/Fabien“»

Грамотный человек поставит после слова «допустим» запятую, а парсер это не схавает. И всё вывалится. Ну это как частный пример.

А суть в том, что для описания хотелось бы использовать более формальный язык, тот же PHP, например. Там большинство ошибок можно исправить на этапе написания, а большинство команд можно написать правильно сразу с помощью автодополнения.
Грубо говоря, смотреть всё время в список regex'ов и выискивать там нужную команду я не хочу.
У вас коренное непонимание принципов сценарного BDD, откуда явный перекос в спецификации. Почитайте dannorth.net/whats-in-a-story/ на досуге ;-)
Да, возможно я имею ввиду что-то среднее между BDD и функциональным тестированием. От первого хочу видеть возможность более явно указывать сценарий, от второго — описание теста на языке программирования.

Просто в моем понимании тесты пишутся программистами, а значит удобнее описывать используя всё богатство инструментариев, которое дает полноценный язык программирования.
Просто почитайте статью.
Насколько я понял, тут отличия где-то в том же чем TDD отличается от написания тестов. TDD предусматривает методологию разработки, частью которой является написание тестов. То же и с BDD. Исходя из описания, BDD хорошо подходит, когда описание сценариев это совместный продукт тестера, менеджера, заказчика и программиста. Когда же сценарий пишется самим программистом для себя или «по мотивам» фичи, с целью просто покрыть функционал, то именно методология немного излишня.

Скажу иначе, как программисту мне будет трудно убедить руководство использовать BDD в проекте. Но лаконично писать сценарии для своего функционала я могу и без использования самой методологии. Так же плюсом является возможность показать тестеру какие действия выполняет мой тест и почему, например, тест проходит, а его действия — нет.

Т.е. у меня есть конкретная цель — покрыть проект функциональными тестами с простыми сценариями и понятными описаниями, доступными непрограммистам. Именно по этому мне нравится Behat и BDD вцелом, но тесты должны оставаться тестами, а не частью методологии разработки. За неё я не отвечаю.
Вы все правильно поняли.

Behat — тул для BDD разработки. Вы же не используете BDD, вы просто пишете функциональные тесты. Behat без BDD — это как машина без колес, все верно ;-)
Ну вот, в этой хабровской заметке как раз идет речь о том, чтобы использовать Behat для функциональных тестов. Можно было бы изначально сказать, что пример малость не верен.

Потому я и спрашивал, можно ли заменить язык сценариев, чтобы использовать существующую инфраструктуру для написания функциональных тестов, но при этом писать тесты не так, что никто не поймет что там происходит, а в более явном виде.
Вы подменяете понятия:

«писать тесты не так, что никто не поймет что там происходит, а в более явном виде»

Сценарии как раз и пишуться для того, чтобы кто угодно понял что там происходит без необходимости понимать как это реализовано ;-)
Да, но не обязательно писать это именно на человеческом языке. Точно так же можно писать на PHP. ПРи этом совершенно не сложно сделать так, чтобы код был понятен обычному человеку. Хотя бы тестеру.
Код по определению не может быть понятен обычному человеку. Ну или у нас слишком разняться понятия «обычности».

Если перед вами стоит задача писать простые функциональные — никаких проблем. Пишите хоть на JAVA. Но не называйте это BDD! Когда я говорю «сценарий», я имею в виду «поведенческие сценарии», являющиеся частью методологии, а не то, что называете сценариями вы ;-)
Ну да, дяде васе с улицы тест понятен не будет, тут согласен. Впрочем, это и не нужно.

Мне, как было сказано, пофиг каким DD это будет называться. Есть сценарии описанные простым языком. В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.

Вроде же разобрались, что я говорю конкретно о функциональных тестах. Модель BDD просто помогает упростить их спецификацию.

Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. Он добавляет новую методологию, а с ней и присущие ей сложности. См. заголовок статьи.
«В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.»
Если подразумевается, что никто кроме программистов этот код читать не будет, зачем эти преобразования?
А если подразумевается обратное, то, извините, но ваши описания никто кроме программиста прочитать все-равно не сможет. С хитрыми преобразованиями или без.

«Модель BDD просто помогает упростить их спецификацию.»
Методология сценарного BDD описывает разработку через поведенческие сценарии. Эти сценарии являются ни чем иным, как приемочным критерем разрабатываемых фич и могут быть использованы в качестве приемочных тестов. Но основная идея — именно в коммуникции со стэк-холдерами, продакт-овнерами, менеджерами и иже с ними.

«Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. „
Изящно заменяет. Если вы итак применяете аджайл и используете что-то вроде scrum или другой историйной методологии — вы УЖЕ пишете пользовательские истории. Behat позволяет эти истории использовать в качестве функциональных тестов. Были юзер-стори, остались юзер-стори. Только теперь они исполняемы!

Если вы ватерфолите и не в зуб ногой что такое гибкая разработка, тогда да. Вам будет казаться, что Behat требует излишней дополнительной работы и вам это все не нужно.
Ох ты ж йо. При чем тут методология? Мы же вроде от неё абстрагировались.

Вернемся к простому.

Я пишу тест, он проходит.
Тестер тестирует фичу, она не срабатывает.
Я показываю ему тест, он его понимает и говорит, что то ли он не те данные вводил, то ли выполнял не те команды.
После того как мы с тестером согласны, что сценарий напиан правильно и у него он срабатывает, фича считается работающей и проверяется на каждой итерации тестирования.

Вот и всё что я хочу. Behat не нужен мне в плане методологии. Я ею не занимаюсь. А вот тестами и коммуникацией с тестировщиком и менеджером — постоянно.
Да, и кстати конкретно в этой хабровской заметке Behat подается как альтернатива функциональному тестированию. О похожей альтернативе я и говорю. Она не требует соблюдения всех формальностей описания Story.
Я вообще имел в виду, что для написания функциональных тестов использовать xUnit не самое разумное решение и есть специализированные инструменты. Все остальное ниже за меня написали :)
Behat — альтернатива не функциональному тестированию, а альтернатива функциональному тестированию через PHPUnit. Ну и конечно же один из способов BDD разработки.
Лучше для функционального тестирования использовать специализированные инструменты, мне кажется, например, selenium или selenium rc. Хотя, функциональные тесты на, например, XML-API мы тоже пишем на xUnit.
Вместо отдельного Selenium'а можно использовать Mink с SahiDriver'ом. Сам, к сожалению, пока не пробовал такого варианта, но выглядит проще и удобнее, чем Selenium.
Причем с помощью прокси можно тестить на разных операционых системах и в разных броузерах.
Sign up to leave a comment.

Articles