Ответ
BDD теряет эффективность в нескольких ключевых сценариях:
- Сложная или абстрактная бизнес-логика. Сценарии Gherkin (
Given/When/Then) могут стать чрезмерно громоздкими и сложными для понимания, если пытаться описать высокоуровневую алгоритмическую логику. - Отсутствие вовлеченности бизнес-стороны. BDD основана на общем языке между разработчиками, тестировщиками и бизнес-аналитиками. Если бизнес-эксперты не участвуют в создании и поддержке сценариев, они превращаются в просто еще один слой автотестов, теряя основную ценность.
- Высокочастотные изменения требований. Постоянные правки в спецификациях приводят к дорогостоящему рефакторингу большого количества BDD-сценариев и шагов в коде.
- Низкое качество сценариев. Сценарии, которые проверяют не поведение, а техническую реализацию, становятся хрупкими и бесполезными.
Пример плохого (хрупкого) сценария:
When I click the button with id "submit-btn"
Then I see the element "#success-message"Этот тест привязан к ID элемента и сломается при любом изменении вёрстки.
Пример хорошего (устойчивого) сценария:
When I submit the registration form with valid data
Then I should see a confirmation that my account was createdЭтот сценарий проверяет бизнес-результат, а не технические детали.
Ответ 18+ 🔞
А, слушай, вот эта ваша модная хуйня — BDD, с этими Given-When-Then, как у просвещённых европейцев... Так вот, она иногда накрывается медным тазом, и сейчас я тебе, дружок, разжую, когда именно.
Первое, блядь. Попробуй-ка описать на этом Gherkin'е, сука, какой-нибудь навороченный алгоритм машинного обучения или квантовую механику в интерфейсе. Ну, давай, начинай: «Given у меня есть тензор ранга 4, When я применяю функцию активации, Then ожидаю, что градиент не затухнет»... Да ёпта, это ж читать будут не только разработчики, а и бизнес-аналитики! Они смотрят на это и говорят: «Это пизда какая-то, а не поведение системы». Для абстрактной, ёбта, логики эти сценарии распухают как дрожжевое тесто, и смысла в них — ноль ебать.
Второй момент, самый пиздецовый. Вся фишка BDD — это общий язык, да? Чтобы бизнес и технари за одним столом сидели и слюной брызгали. А если эти самые «бизнес-эксперты» послали тебя на хуй с твоими сценариями и участвовать не хотят? Всё, приехали. Твои красивые файлики .feature превращаются просто в ещё один, блядь, слой автотестов, который надо поддерживать. Ценность — в рот меня чих-пых — испарилась!
Третье. Требования меняются чаще, чем твоё настроение с похмелья. Только описал сценарий, а тебе уже прилетает: «А мы тут подумали, надо по-другому». И пошёл ты переписывать кучу шагов в коде, а потом ещё и сценарии. Это, блядь, дорого и деморализует, как ёперный театр.
И наконец, четвёртый грех — кривые, хрупкие сценарии. Вот смотри, чтобы не быть голословным:
Пример говна (хрупкий как мои нервы):
When I click the button with id "submit-btn"
Then I see the element "#success-message"Видишь? Это не поведение, это техническая привязка, блядь! Завтра фронтендер поменяет id, и всё, тест сдох, хотя функциональность та же. Пиздопроебибна затея.
А вот пример, как надо (устойчивый, как бык Герасим):
When I submit the registration form with valid data
Then I should see a confirmation that my account was createdВот! Это — поведение, ёпта! Нахуй эти id и селекторы. Проверяется бизнес-результат: аккаунт создался — ок, не создался — не ок. И не важно, какую кнопку нажали и как сообщение вывели.
Короче, инструмент он как молоток: если гвозди забивать — охуенно, а если пытаться им суп хлебать — обосрёшься. Вот и с BDD так же.