testomat.io управление авто тестамиА для тестировщиков, просто появляется еще одна прослойка (в виде features файлов, в виде markdown разметки…) которую надо поддерживать и IDE в этом не поможет.
читайте первую букву как business, тогда все будет ок 
Не могу с этим согласиться:) Любая коммерческая разработка ПО это business driven development - ведь бизнес за нее платит деньги. А вот интересно, есть ли хоть один open-source проект на котором бы применялось BDD, ведь тесты в том числе и функциональные пишутся и на открытых проектах.
Из известных мне проектов - Sylius (ecommerce) использует BDD во всю. Sylius/features at 1.12 · Sylius/Sylius · GitHub
Я думаю все же смысл в том, чтобы у всей команды было общее понимание того, что делает та или иная фича. По этому бенефиты от BDD можно получить в полной мере только тогда, когда в этом процессе задействована вся команда. Самый идеальный вариант, это когда после обсуждения всей командой фичи, аналитик или тестировщик пишет сценарий, который потом ревьювит вся команда. В итоге имеем документ по которому разработчик пилит фичу, а тестировщик проверяет соответствие фичи этому документу. По этому в теории на выходе должен получаться более качественный продукт, т.к. на этапе проектирования фичи участвует вся команда. Хотя это и почти утопия в наших реалиях
2 лайка
ИМХО самый большой анти-паттерн использования BDD - это возложить на него все тестирование. BDD-сценарии были задуманы как попытка удостовериться, что мы делаем правильный продукт, то есть соответствующий бизнес-потребностям заказчика. То есть если мы разрабатываем для заказчика велосипед, то BDD-сценарии должны помочь понять потребность заказчика в этом велосипеде. Хочет ли он с его помощью просто ездить либо же он ему нужен как тренажер для ног, например? И в том и другом случае, возможно, мы поймем что ему нужен вовсе не велосипед (мотоцикл? велотренажер?) и сможем предложить нечто лучшее.
Анти-паттерн, это запихивать в BDD-сценарии проверки не относящихся бизнес-потребностям деталей, а-ля поле для логина должно вмещать не больше 20 символов.
Для этого нужны совершенно другие тесты.
2 лайка
Полностью согласен.
Более того, я не понимаю принцип тестирования, когда мы набираем тестировщиков не способных по названию метода понять то что он делает, а потом исходя из этого строим процессы по автотестированию.
Почему разработчики с таким же успехом не нанимают джунов и не предумывают им “обёртки” с помощью которых можно было бы проще разрабатывать.
Для автотестирования не надо быть гуру ЯП. Если мы говорим что page object готовы, то у вас не должен один метод использовать много раз, т.к. получить текущее состояние нужно другими способами (не обходя весь flow вашего приложения). Тогда становится понятно, что эти степы не нужны в принципе. Т.к. любое новое действие всё равно будет писать автотестер со скилами.
1 лайк
Дело в том, что BDD как он задуман нужен, действительно, только заказчику и аналитику. И это очень ограничивает область применения, потому что далеко не всем заказчикам такие описания нужны.
И тут оказывается, что огурцовый формат может быть полезен для составления подробных функциональных тестов. Зачем говорить, что это плохо, если это реально улучшает работу команды?
Не не способных понять по названию метода, а не готовых читать код. Вообще ни в каком виде. Просто потому что это код. Это как раз еще людей с нашей стороны можно приучить, а когда есть тестирование на стороне заказчика - это вообще нереально, т.к. там в тестирование идут не программисты, а пользователи, которые хорошо знают область применения программы.
Дешевле будет написать обычные тест-кейсы и с линковать автотесты и тест-кейсы по id.
1 лайк
Никто не говорит, что это плохо - просто называйте это своими именами - Keyword-driven который уже слегка “бородат” и задумывался для реализации “утопии”: что тесты будут писать люди без технического бекграунда.
Дайте им внятный репорт. Все равно на сложном проекте не возможно будет написать технично сценарий не заглядывая в код.[quote=“checo, post:31, topic:15132”]
а когда есть тестирование на стороне заказчика - это вообще нереально, т.к. там в тестирование идут не программисты, а пользователи, которые хорошо знают область применения программы.
[/quote]
Там уже давно все меняется, хоть и не так быстро как хотелось бы, и каждый product owner у которого есть автоматизация приходит к тому что простые “ручники” ему не выгодны.
1 лайк
На мой взгляд BDD не правильно интерпретируют, особенно это опасно когда инициируют внедрение не технические специалисты (я участвовал в этом внедрении в компании 200 чел девелопента, 20 лет проекту). Главное это язык который использовать, и первая попытка-это использовать бизнес английский, тут и начинается веселье: первые 10 или 100 тестов еще ничего, но потом люди понимают, оказывается мы пишем свой собственный транзитный язык с английского на С#, а это очень затратно. Прибавьте к этому, что бизнес язык в каждом отделе разный и люди начинают спорить, и в итоге оказалось что самый простой язык для наших REST API тестов оказался очень техническим (как Postman, только в Specflow). А вишенка на торте, что бизнес в редком случае заглядывает в эти тесты (в моем случае никогда). В итоге мы использовали Specflow, что бы построить своего рода адаптер для HttpClient(библиотека которая отсылает запросы), которы предоставляет своего рода упрощенный REST язык для написания тестов. На мой взгляд , нужно всегда смотреть на BDD с точки зрения эффективности кода, иначе образуется черная дыра, которая пожрет все ресурсы, а фокус должен быть на тех людях, которые тесты поддеррживат.
Это кстати тот вопрос, на который я никак не могу получить ответ от адептов BDD - какая проблематика решается с помощью данного подхода. То есть назовите причину, которая сначала была выявлена, детализирована - а потом решением данной проблемы был выбран BDD, при том, что решения выбирались не вслепую, а как то оценивались
Создание DSL, который понимает бизнес и девелопмент, через игровую форму G|W|T. Причем что бы добиться хороших результатов, все должны в него уметь контрибьютить - иначе рано или поздно будет адъ.
А - ну и домен бизнеса должен соответствовать - я видел много проектов, на которых создать внятный и компактный dsl не представляется возможным.
большинство из вышесказанного описывает эта статья
1 лайк
1 лайк