testomat.io управление авто тестамиЗдравствуйте. Расскажите пожалуйста тезисно, в чем преимущества и недостатки написания тестов в BDD стиле? Пишу тесты на JBehave, проблем особых не вижу и мне не принципиально, писать стори или junit тесты, но на собеседованиях людей очень тревожит эта тема и постоянно сталкиваюсь с вопросами касаемо того, что лучше/удобнее, какие плюсы/минусы, почему так, а не иначе. Сам конкретных плюсов/минусов выделить не могу, а в дискуссиях на конференциях по этой теме вижу много воды без конкретных выводов. Не могли бы вы по пунктам написать, в чем же все таки преимущества и недостатки BDD подхода? Благодарю.
BDD это сквозной процесс при производстве ПО (как Devops). Если только в тестах используются аннотации в BDD-стиле, то это просто тесты с геркин-аннотациями (человекочетаемые), которые мапятся на готовые тестовые методы.
На моем текущем проекте геркин помогает. Я автоматизирую “готовые” тест-кейсы, которые хранятся в АЛМ. Написаны они часто не очень аккуратно. Это мне помогает так:
- Четкое формулирование тест-кейса по шагам
- Результаты прогона теста Allure приаттачиваю в ALM + геркин шаги.
- Ручные тестировщики и аналитики проверяют насколько автотесты правильно работают.
минус для меня один- это дополнительный слой абстракции в коде. Но он небольшой, особенно с учетом того, сколько всего уровней абстракций уже есть ))
Если вы на небольшом проекте и отвечаете за весь процесс тестирования, то геркин-аннотации это оверхед.
3 лайка
Только написание тестов в BDD стиле не несет профита само по себе. BDD предпологает взаемодействие Dev, QA и Business команд которые создают фичи совмесно. Как следствие создаются понятные всем командам тест артефакты и документация. Если же только тестировщик пишет BDD стиле, мы получаем теже тесты только в BDD стиле, которые если необходимо можно показать бизнесу так как они human readable, и оверхед при их написании.
Писал тесты в BDD стиле довольно долгое время и сегодня, прознав всю мощь и красоту фикстур и различных фишек PyTest (в других языках свои аналоги), категорически отговариваю всех спрашивающих использовать BDD как основной стиль разработки автотестов. Ибо как бы вам не пели разные докладчики что это очень крутой человекочитаемый тест, который сможет написать каждый мэнуал тестировщик - чушь, писать степы для проверки состояния все равно придется автотестеру. Еще минус - подготовка тестового стенда. Копировать шаги из одной фичи в новую? Реально? Очень смешно при условии что цепочкой фикстур пайтеста стенд собирается сам собой. Да, конечно, менеджеры в восторге - зеленые шаги, красивые отчетики…Только кроме отчетов есть еще 3-4 уровня абстракции, где могут быть совсем не тривиальные баги. Менеджерам пофиг, а вам поддерживать. В том же самом Behave на питоне приходилось втыкать столько костылей, что уже жалко потраченного времени. Выбирать конечно вам, но я бы потратил денек чтобы доказать менеджеру что нам не нужен BDD, дабы сохранить себе время и нервы на ближайшее рабочее время.
6 лайков
Как было сказано выше, следует различать 1) BDD как стиль разработки и 2) просто тесты в BDD стиле с ипользованием JBehave/Cucumber/etc. Скорей всего, на собеседованиях вас спрашивают как раз про п.2 и ожидают услышать сравнение тестов с архитектурой BDD и тестов с каким-нибудь xUnit фреймворком.
Плюсы написания тестов в BDD стиле:
- самое главное - BDD позволяет организовать тесты в т.н. 3-layer архитектуру, в которой каждый уровень имеет свою область ответственности. Эти уровни можно условно рассматривать как технический (webdriver + page objects), уровень атомарных шагов (steps), на котором пишутся действия пользователя, и уровень definitions, где эти шаги организуются в Gherkin сценарии.
Технический уровень отвечает на вопрос “КАК” (как работает ваш автотест, какие локаторы он ищет, какие кнопки нажимает и т.д.), уровень шагов отвечает на вопрос “ЧТО” (что делает автотест - делает логин, добавление товара в корзину и т.д.), а вот уровень definitions отвечает на вопрос “ПОЧЕМУ” автотест это делает. Таким образом мы получаем бизнес ценность наших тестов и можем правильно решить, что стоит автоматизировать а что нет. - улучшенная читаемость (тесты пишутся человеческим языком в отдельных текстовых файлах, их проще читать чем даже хорошо написанный код);
- отдельные плюшки от BDD фреймворка, который мы используем (организация и запуск тестов, менеджмент вебдрайвера, готовая архитектура и т.д.)
Минусы:
- более сложный сетап тестового фреймворка;
- замедление работы тестов из-за недостатков самого JBehave/Cucumber/etc;
- высокий порог вхождения для новичков (нужно не только понимать работу всех компонентов фреймворка, но и уметь правильно писать Gherkin сценарии)
- усложненная итеграция с другими компонентами тестового фреймворка (репортинг, парелеллизация и т.д.);
- применение не везде оправданно (для тестирования условно какого-нибудь хеллоуворд приложения использовать xUnit фреймворк будет быстрее и удобнее)
3 лайка
2 лайка
Можно про pytest по подробнее как раз начал изучать
Да не вопрос, начните с этой инфы:
https://habrahabr.ru/post/269759/
Затем основную доку:
https://docs.pytest.org/en/latest/contents.html
Ну и еще немного фишек по фикстурам есть в этой презенташке:
http://devork.be/talks/advanced-fixtures/advfix.html
1 лайк
Отмечусь от себя здесь, в основном про недостатки:
) BDD это язык. Это новый язык, его реализовать вам, а не сделают за вас. В любом случае это overhead — “нагрузка”: вы создаете второй, “человеческий” язык для описания того что и так будет описано кодом. Я видел отзывы что это может хорошо работать, но лично видел только как это работает плохо.
) Нужен “централизованый орган”, который этот язык будет стандартизировать и поддерживать. Например, из статьи о BDD в “Тинькофф”: “Мы остановились на описании полной иерархии страниц и их элементов…” — это полное описание живет и работает где-то централизованной группой.
Если вы сразу видите что полное описание страниц/экранов и элементов может потянуть на много-много-много страниц и времени, то скорее всего затрат на BDD у вас будет больше чем пользы.
) BDD лишь ограниченно соответствует алгоритмическим языкам. Это “линейный” язык (сценарии линейны), без условных операторов, циклов и пр. Есть мнение что так и надо, есть мнение что это далеко не всегда хорошо (я придерживаюсь последнего). Т.е. нужно придумывать какому коду будут соответствовать фразы BDD, как это реализовать.
) Этот язык требует обучения и коммуникаций. Нельзя просто так взять и писать на Геркине что попало — сначало надо посмотреть и согласовать что уже написано, как и в каких терминах оно написано, всяко стремиться к повторному использованию (reuse). Если у вас нет много повторного использования, BDD, опять же, может значить для вас больше проблем чем решений.
) Если у вас, скажем, всего два-три автоматизатора, вполне возможно что они в этом загрузнут по уши (это было причиной отказа от BDD в тех случаях где я это видел).
) BDD нужна техническая поддержка, и значительная (в вышеупомянутой статье от Тинькоффа описано сколько им пришлось дорабатывать — свой плагин, база локаторов (языка), база BBD-фраз (видна на демо-анимациях), база тестовых данных…
Для небольшой команды усилия по BDD скорее всего того не стоят: они значительны, а эффект может оказаться меньше потраченных усилий (также см. ниже).
) Если ваша продуктовая палитра содержит “много всего”, например веб-портал, пару мобильных приложений, веб-приложение отличное от портала… — вам будет тяжело работать с BDD, потому что нужно много-много языковых элементов.
) BDD не обязательно ускоряет, или опережает. Цитируя опять же статью от Тинькоффа, “Классический вариант {x}DD, когда изначально пишутся все тесты, и только потом начинается непосредственная разработка, в изначальных наших условиях сильно повлиял бы на наш быстрый релизный цикл, что для банковских сервисов непозволительная роскошь.”
Если вам критично что-то зарелизить быстро, вам нужна либо мощная поддержка которая будет быстро писать переводы кода на BDD язык, либо BDD вам для быстрого релиза не нужно. Если вы делаете новый функционал, который надо одновременно исследовать и тестировать как он работает (у меня такое было вот недавно) — Вам BDD тоже вряд ли нужен.
Опыт из которого это написано: три проекта где пытались внедрять BDD.
- Очень сложная и разноплановая предметная область, сотни разных приложений и экранов. Туда вообще было бы лучше не соваться с BDD. Итого: BDD выкинуто.
- Реализация через BDD (Specflow) формально работала, но ничем не помогла. Вина тут скорее была не BDD а сложности тестируемой системы и проблем с ее аппаратной, но особенно програмной частью (свой проприетарный сервер, своеобразная реализация с использованием Appium). Не расширив особо ни фич ни покрытия, проект закрылся.
- Опять таки разноплановая предметная область, хотя и не такая архисложная как в случае 1, но большая. Поддержка BDD требовала значительных отдельных ресурсов программистов, BDD-описания кейсов выходили большими, сложными, непонятными. На него перестали выделять ресурсы и благополучно похоронили. Т.е. хотели “кейсы на BDD читабельные для всех”, а получилось “ни для кого”.
5 лайков
Поделитесь ссылкой на эту статью про BDD от Тинькова?
Кстати, в основном проблема BDD в плохой вовлеченности бизнеса, если бы заводились требования к которым привязывались тесты и по ним отслеживались метрики покрытия и готовности тех или иных фич, то это бы могло заработать. Возможно, что где-то это так и работает. Тогда бы и автоматизацию делали сами разработчики, т.к. критерием готовности фичи являлось прохождение всех тестов привязанных к требованиям.
добавлю еще одну ссылку сюда
Пожалуйста: Автоматизация по методологии BDD. Наш опыт успешного внедрения / Habr
Я полагаю что основные проблемы BDD это
-
то что он дополнительная работа, которую нужно делать на ограниченном языке, для которого прописывать некую костыльную поддержку… и, конечно же, тратить на это время.
-
“новые правила жизни”. Да, действительно, может не быть полных требований наперед: работать так стало слишком медленно.
1 лайк
Один раз сталкивался с BDD в кампании. Изначально неправильно выстроенный процесс привел к отказу: и от BDD, и от автотестов. Что в данном кейсе касается BDD:
- Бизнесу нравится. Но факт - BDD пилят ручные тестеры. И только они. Ни бизнес, ни кто-либо другой не запилил ни одного.
- Ручники часто не успевают, потому что большой беклог на тестирование, а кейсы BDD - это в дополнительную нагрузку, после…
- Лишний слой абстракции для автоматчика, и получается: нужно переговорить с ручниками по поводу написанных кейсов (поправить кейсы / не все понятно по процессу - нужны пояснения и т.д.), нужны кейсы (а их еще не успели запилить - см.выше), старые кейсы уже не актуальны (нужны правки).
3 лайка