Паттерны и анти-паттерны использования BDD. Опыт реальных проектов

база знаний
, , , ,
#1

Сейчас активно обсуждаем вопрос паттернов или даже больше АНТИ-паттернов использования #bdd подхода в разработке и автоматизации тестирования. Есть целая куча различных факторов, когда этот подход не сработает или будет работать неправильно. Хотелось бы услышать ваши паттерны или анти-паттерны которые вы использовали при внедрении #bdd на реальных проектах?

image.jpg1272×1096 366 KB

Далее пару интересных ссылок и материалов по этому поводу:

Если коротко выделить анти-паттерны, то получиться вот такой вот список:

  • Bad collaboration
    • When do you write feature files
    • Business people create scenarios in isolation
    • Devs or testers writing scenarios without talking to business people
    • Too high level
  • No living documentation
    • When you read Gherkin and it is bad documentation
    • Incidental details
    • Hard to tell what you are testing
    • Bad name on a scenario
    • Not using the narrative section of a feature
  • Beginners mistakes
    • Lots of user interface details
    • Describing actions using the personal pronoun I
    • Documenting boring scenarios
    • Keeping all scenarios forever
    • No clear separation between Given/When/Then
    • Multiple When
  • Double edged sword
    • Scenario outline
    • Multiple Then in the same scenario

Вы использовали BDD?

  • Да
  • Нет
  • Не знаю

0 участников

Какие результаты внедрения получили?

  • Положительные, стало лучше чем было
  • Негативные, все стало хуже
  • Не знаю

0 участников

Будете ли вы применять bdd на будущих проектах?

  • Да
  • Нет
  • Не знаю

0 участников

Какие ваши мысли по поводу использования #bdd на реальных проектах?

Каковы преимущества и недостатки BDD подхода написания тестов?
py.test-bdd или behave. Что бы вы использовали? Плюсы и минусы
Каковы преимущества и недостатки BDD подхода написания тестов?
#2

Что-то многие #bdd недовольны, или не научились правильно использовать, или действительно подход применим если очень много факторов выполниться (в том числе правильно реализованная автоматизация)

#3

Миша, думаю проблема в том, что если вся команда не работает по BDD, то он и не заходит) Думаю просто не очень распространённая практика у нас в СНГ. Ну и нужна команда из самоорганизованных толковых людей. Аджайл то не везде выходит. У нас вон ватерфлоу засунутый в спринты… Так и живём :smiley:

2 лайка
#4

Вот интересно почему, ведь много забугром используют подход и довольны им.

Что правда, то правда …

#5

Не выходит каменный цветок

#6

Ну может и мы когда-то дойдём)

Мне кажется BDD может прижиться только в маленьких и очень сплоченных командах, в стартапах там разных. А стартапов как известно у буржуев больше. У нас кругом одно аутсорсище:frowning:

3 лайка
#8

Мне почему-то кажется, что это не проблема BDD. Что с ним, что без него - проблема никуда не девается. Просто многие смотрят на BDD, впрочем как и на agile, как на “серебряную пулю”.
Многие из приведенных аргументов “против BDD” к нему не имеют отношения и лежат в параллельной плоскости. Просто кто-то думает, что может техническими средствами решить организационные проблемы, что в корне неверно.

С точки зрения автоматизатора, щупал bdd в виде огурца и в принципе особых проблем с ним не увидел. Небольшой оверхед имеется, но весьма незначительный.

#9

@Mihail_Bratuhin проблема как всегда не в инструментах, а в вариантах его использования, или даже в людях, которые следуют определенным процессам, в котороых #bdd не очень эффективен

1 лайк
#10

Согласен с антипатернами в топике

Мне лично нравится стиль записи сценариев в BDD при условии хорошего стиля записи + способствует мышлению в сторону реюза шагов

Относительно тестового сценария для автоматизации в этом стиле - парочка моих наблюдений:
1) - Слишком длинные шаги предусловия. - антипатерн
Given A
And B
…
And .Z
Решение: агрегировать группу шагов из предусловия в один шаг
например ->
Given user state is ‘ABC’

2) Разделять взаимозависимые шаги. - антипатерн
Например плохая практика писать ->
GIven A
And B
где B всегда требует чтобы выполнился A

Плохо тем что существует возможность забыть про эту завимость и вставить в сценарий только Given B

Решение: соединить в один Given C который будет равен A+B
и избавится от шага Given B и по возможности Given А

  1. Так же мне нравится использовать префиксы в имени шагов чтобы обозначить экран, функционал, сервис с которым данный шаг работает - помогает избегать дупликации шагов когда над сценариями работает много народу и позволяет использовать autocomplete
3 лайка
#11

Бдд это хорошо, когда нужно покрыть акцептанс кейсы. Ясно, что покрыто, а что нет - разработчиками и тестировщиками.

#12

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

2 лайка
#13

Есть опыт работы у буржуев в большом инвест банке. Там BDD была политика партии - усердно старались применять (user story писать, практики внедрять), потому что модно и современно. Большие копрорации очень сильно задумываются сейчас что противопоставить всяким хипстерским стартапам.

1 лайк
#14

И я их мнение полностью разделяю. Ведь если вдуматься, какова основная причина почему люди используют BDD? ИМХО для того, чтобы можно было на работу брать тестировщиков без глубокого знания ЯП, ведь он может использовать заранее готовые степы для построения своих фич. Ведь по сути, когда уже реп живет достаточно давно, то Given и When шаги уже покрывают достаточно много тест кейсов и остается дописать только Then шаги (проверки зачастую бывают специфические). Тем более, лучше же взять на работу джуна и приучить его к BDD каше, чем взять мидла который будет плеваться типа “BDD не нужен”, тем самым якобы набивая себе цену

#15

Вопрос - это плохо или хорошо?
Для меня лично тот же огурец весьма удобен. Особенно когда действительно уже многие степы готовые.

#16

Правильно, если кодовая база наработана - джуна так же легко приучить и к ЯП каше - никакие глубокие знания тут не нужны.

А я бы задумался, сколько из этих людей использует BDD как методологию, а не мимикрирующий под него Keyword-driven - думаю цифра сократится на несколько порядков.

2 лайка
#17

думаю цифра сократится на несколько порядков

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

#18

Ага - если только тесты в такоем виде пишутся то получается Keyword Driven + AAA (Arrange Act Assert) - что уже две неплохие практики :slight_smile:

#19

У меня был именно опыт в Scrum проектах, где были User Story в виде
As a user role, I want to objective so that benefit
Story писали бизнес аналитики совместно с бизнесом и забивали их в Jira
Story должна была составлена согласно INVEST принципу ( INVEST in Good Stories, and SMART Tasks - XP123 )
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
На refinement сессиях вместе с Scrum командой эти Story дополнялись описанием тем что нужно было сделать (Acceptance Criteria list + Tasks)
Далее на базе этой Story и Acceptance Criteria команда (необязательно тестировщики) писали сценарии Given-When-Then и автоматизировали их

В целом в процессе работы с таким подходом было хорошее понимание зачем каждая фича и что мы делаем - что круто!

4 лайка
#21

Аргумент против BDD, который чаще всего приходилось слышать - это увеличение размера кода без определенной цели. Действительно, зачем автоматизатору что-то усложнять и оборачивать, если в итоге с автотестами работает только автоматизатор?

Когда командная работа дает ответ на вопрос “Зачем?”, сомнения должны уйти. А если ответов нет, тогда и правда незачем.

По своему опыту, могу сказать, что успешно удавалось решить такие задачи:

1) Наглядность, или ответ на вопрос "Что делают тесты?"

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

Другое дело, что кто-то должен читать тесты на постоянной основе. Если это никому не нужно, или нужно 1 раз, то и незачем городить.

2) Внесение автотестов в тест-трекер.

Без комментариев. Тесты всем доступны, читаемы, расположены в одном дереве с ручными, и ни у кого не возникает вопросов, какая часть спецификации покрыта.

3) Написание автотестов мануальными тестировщиками.

Реально? Да, реально. Если команда к этому готова. Разумеется, здесь нужен импульс от руководства.
Кстати, в этом случае “Eyes on the screen” (со слайда 53) и “Cucumber test scripts” (со слайда 74) не являются антипаттернами. Наоборот, неконкретные шаги непонятны для тестировщиков. Тесты проверяют конкретную функциональность. Формулировка шага не должна вызывать вопросов “А что он делает?”. Тогда люди будут писать.

С моей точки зрения, наоборот, слишком “правильный BDD” является антипаттерном. Это когда говорят, что ни в коем случае не надо писать сценарии, а только обобщенные требования в 3-4 строчки (Given-When-Then). Это как раз и приводит к тому, что о содержании шагов будет знать только автоматизатор, и такие тесты становятся никому не нужны. Легче просто код писать.

3 лайка
#22

Меня всегда интересовало, а в какой момент вдруг объединились BDD и тестирование. ИМХО, BDD это тот же самый TDD - только перенесенный с уровня юнит тестов, на уровень поведения. BDD применяется разработчиками с той же целью, что и TDD - это не покрытие, не автоматизация без знания ЯП, это уверенность в том, что внесенные изменения не сломали поведение системы. При чем здесь тестирование?