Bdd что это

Что такое BDD в чём его отличия от TDD?

BDD — behaviour-driven development — это разработка, основанная на описании поведения. То есть, есть специальный человек(или люди) который пишет описания вида «я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке». (там есть специально выделенные ключевые слова). Программисты давно написали специальные тулы (например, cucumber), которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста). А дальше классическая разработка с тестами.

В чем преимущество BDD?

• тесты читаемые для не программистов.
• их легко изменять. Они часто пишутся почти на чистом английском.
• их теперь может писать product owner или другие заинтересованные лица.
• результаты выполнения тестов более «человечные».
• тесты не зависят от целевого языка программирования. Миграция на другой язык сильно упрощается.

(слово тесты выделено не случайно, потому что теперь тесты это и описания, и непосредственно их реализация.)

Отслеживать
ответ дан 18 апр 2017 в 7:37
112k 6 6 золотых знаков 93 93 серебряных знака 159 159 бронзовых знаков

Строго говоря, то что вы описали — это End2End или Acceptance тесты. BDD бывает и без «оторванных» от языка программирования описаний. Для ruby это, например, RSpec — модульное тестирование в BDD стиле.

18 апр 2017 в 8:02

основное отличие Cucumber и RSpec — это то, кто пишет «тесты». В первом случае это «бизнес», во втором — «разработчики».

18 апр 2017 в 8:25

Это понятно. Я просто к тому, что в BDD тесты пишут не обязательно «бизнес-люди». Иными словами, говоря «я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке» вы ограничниваете BDD только до Acceptance-level тестов, что не верно. RSpec — тоже BDD-way, а он вполне себе Unit-level.

18 апр 2017 в 8:33

а я и не утверждал что их пишут только бизнес-люди. Я сказал, что теперь их могут также писать и бизнес люди. А это дает большую гибкость (потому что теперь нужно меньше переводчиков с «бизнес языка» на «программерский»)

18 апр 2017 в 8:35

Эм. «То есть, есть специальный человек(или люди) который пишет описания вида. » А про BDD Unit тесты написанные программистами для программистов в вашем ответе как раз ни слова.

Опыт использования BDD

Около семи лет назад Dan North в своей статье описал практическое применение BDD подхода, который позволяет сделать процесс разработки более понятным и управляемым путем налаживания внутренних коммуникаций. Индустрия с каждым днем проявляет всё больший интерес к этой методологии, нацеленной на продуктивное взаимодействие стандартных команд типа «аналитика-разработка-тестирование».

Однако, сейчас лишь малая часть компаний решается на использование BDD. Почему?

Итак, давайте разберемся. BDD (Behaviour Driven Development — «Разработка через поведение») — гибкая методология, тесно связанная с TDD (Test Driven Development — «Разработка через тестирование»). По опыту, даже матерые тестировщики зачастую не видят разницы между этими методологиями. Действительно, на первый взгляд ее трудно вычленить: оба подхода предполагают написание документации и тестов до старта этапа разработки. А различие вот в чем: в BDD для описания тестов требуется использование естественного языка, понятного каждому участнику проекта, чтобы, фактически, объединить постановку задачи, тесты и документацию воедино. Другими словами, определяется DSL (специфичный предметно-ориентированный язык), потом составляется стандартный ограниченный набор фраз, описывающих поведение нужных элементов. Затем с их помощью разрабатывается сценарий использования новой функциональности, который будет понятен всем.

Давайте один раз увидим разницу, и она станет очевидной:

Мы еще коснемся этого примера, а для начала давайте посмотрим на все разнообразие методологий, которые на данный момент имеют ненулевую актуальность.

Сравним несколько методологий

Диаграмма ниже показывает сравнение трех подходов: TDD, TLD (Test Last Development) и BDD:

• Когда мы работаем по методологии BDD, автотестирование и составление спецификации сопровождает каждый этап цикла разработки ПО, что обеспечивает постоянную актуальность автотестов и документации.
• Методологии TDD и ATDD (Acceptance Testing) объединены на диаграмме в один блок, т.к. пишутся на этапе аналитики. Как уже было сказано выше, TDD основан на написании тестов до разработки функционала. Разработчик должен написать тесты для того, чтобы написать функционал под тест.
• TLD (Test Last Development) включает тестирование после реализации функционала.
• BDD универсален и может включаться на любом этапе разработки.

На второй диаграмме изображено вовлечение участников процесса разработки в написание сценариев.

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

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

Это о плюсах. Тем не менее, как уже было сказано, несмотря на большое количество плюсов, мало кто эту методологию внедряет.

BDD всем хорош, но почему его не используют?

Ответ прост: это долго и дорого. С этим утверждением согласятся большинство IT компаний. И поначалу мы не были исключением. BDD неудобен хотя бы тем, что требует привлечения специалистов тестирования уже на этапе проработки требований.

BDD переворачивает с ног на голову классическую схему ведения разработки (TLD). Она плохо реализуема, потому что это сложно. Удлиняется цикл разработки.

BDD — это несомненно способ достичь качества. Но не все готовы платить временем и специалистами за это качество.

Однако, что делать, если BDD все же хочется внедрить?

Можно попробовать использовать готовые фреймворки. Например Cucumber, Squish, Yulup.

Основная проблема сложности BDD не в процессе, а в реализации и существующих инструментах. Возьмем в качестве примера WEB разработку корпоративной информационной системы. Имея web реализацию мы сталкиваемся с WebDriver’ом являющимся в данный момент стандартом при автоматизации приложений, работающих в веб браузере. Он обладает довольно большими возможностями. Для учитывания различных кастомизаций элементов страницы необходимо придумывать варианты обращения к ним. И тут для облегчения разработки теста на помощь приходят различные библиотеки (Selenide, и др.), что создает свою экосистему, которую нужно знать. Для работы с WebDriver нужен программист либо тестировщик-автоматизатор, т.к. все реализуется с помощью кода и хитрых конструкций.

Начало работы с BDD фреймворком — сложно и долго

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

В Gauge тесты пишутся в файлах спецификаций (файлы с расширением .spec). Спецификация содержит шаги теста, написанные на естественном языке. Эти шаги имплементируются на каком-либо языке программирования (у нас был использован язык программирования Java). При имплементации шагов важно соблюдение Naming Convention как в именах файлов сценария и реализации, так и в именах методов реализации и шагов сценария, они должны полностью совпадать. Дополнительную гибкость этому инструменту даёт то, что шаги могут иметь параметры.

Gauge позволил нам использовать плюсы BDD. Однако мы все равно столкнулись с проблемами, которые заключаются в сложности реализации: проблемы инструментария и внедрения процесса.

Оказалось, что привлечение тестировщиков на раннем этапе плохо сказывается на конечном результате. Увеличивается время на разработку тестов. При использовании любого фреймворка требуются большие усилия тестировщика, который, несомненно, хорошо должен владеть и программированием. Поначалу процесс работы со сценарием был следующим: аналитик рассказывал тест тестировщику, а записывал его технический писатель. Пока тестировщик разбирался с программной реализацией, изменялся смысл тестируемой функциональности. Тут сказывается разделение точки входа, а она должна быть одна, по итогу процесс разделяется и превращается в “обычный” процесс, от которого как раз и хотелось уйти. Т.е. точка входа разделилась, коммуникации расползлись, тестировщик ушел с головой в имплементацию теста, технический писатель понял как-то по своему, а аналитик уже и свои доки переписал и передумал, разработчик же вообще ушел в “свой мир” ).

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

Работа тестировщика вначале выглядела следующим образом:

1. Изучение документации, если она есть;
2. Составление чеклиста;
3. Ad-hoc тестирование;
4. Составление тест плана;
5. Уточнение картины мира у аналитика;
6. Уточнение картины мира у разработчика;
7. Если все срослось, написание тестовой документации, параллельно с тестированием;
8. Ожидание фикса багов, тестирование багов;
9. Описание страниц, контролов, поиск элементов на странице используя Web-Driver. Поиск того что уже реализовано в системе тестов;
10. Написание логики теста;
11. Релиз;
12. Support bug/Regress bug;
13. Обновление спецификации;
14. Фикс бага;
15. Обновление автотеста, обновление большого количества изменившихся контролов;
16. Релиз;
17. …
    Пункты, выделенные курсивом, (1, 5, 6, 7, 9, 13, 15) приводят к временным затратам. Их можно и нужно оптимизировать.

Этот список кратко проиллюстрирован на диаграмме процесса разработки:

Наша компания специализируется на проектах с веб реализацией интерфейсов. Исходя из этого, мы используем инструмент Web Driver для взаимодействия с веб браузером.

Де-факто, Selenium Web Driver является стандартом, и он используется для описания веб объектов на любых фреймворках, в том числе Gauge, jUnit, библиотек Masquerade и других. Гибкости у него много для разных задач, что создает излишнюю трудоемкость в локально-типовых задачах. Нам нужно найти решение для уменьшения трудоемкости.

Для примера покажем на схеме — как связаны Selenium Web Driver, фреймворк Gauge, библиотека Masquerade, язык программирования Java.

В этой схеме можно вместо BDD фреймворка поставить jUnit, TestNG или любой другой, любая связка будет работать, в зависимости от потребностей. Selenium и Masquerade останется, язык программирования можно изменить.

Ускорение процесса написания кода — подключение Masquerade

В нашей компании разработка ведется на платформе CUBA. И специально для этой платформы был разработан инструмент для автотестов: Masquerade — библиотека, которая предоставляет лаконичный и удобный API для работы с кодом при имплементации тестов с использованием WebDriver. Эта библиотека работает над Selenium Web Driver, дружит с selenide и любыми фреймворками.

В CUBA проектах каждый элемент веб страницы содержит cuba-id, который не меняется. В CUBA используется компонентный подход, а библиотека Masquerade упрощает взаимодействие с элементами веб страницы. Библиотека умеет совершать действия с элементами веб страницы, реализованными с помощью CUBA, более простым образом. Поэтому при поиске элементов на странице не нужно использовать громоздкие конструкции с XPath, как было раньше:

$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click();

Или более лаконичные конструкции на Java, которые, тем не менее, по-прежнему громоздки:

private static void click(String cssClass, String caption)

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

В коде страницы нам виден четко узнаваемый элемент cuba-id=”loginButton”

Опишем кнопку, используя библиотеку Masquerade:

@Wire(path = ) private Button loginButton;

Простой вариант реализации теста на фреймворке jUnit — блок авторизации, который выполняется перед каждым тестом:

@Before public void loginAdm()

А в теле метода login следующий код:

LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click();

При этом самое важное — то, как мы описываем страницу, как мы обращаемся к элементам. Описание страницы LoginWindow:

public class LoginWindow extends Composite  < @Wire(path = ) private TextField loginField; @Wire(path = ) private PasswordField passwordField; @Wire(path = ) private CheckBox rememberMeCheckBox; @Wire(path = ) private Button loginButton; >

Поиск элементов — это лишь часть возможностей библиотеки Masquerade. Обращение к элементам веб страницы позволяет совершать различные действия с этими элементами. Например, можно выбрать элемент из выпадающего списка:

getMaxResultsLayout().openOptionsPopup().select("5000")

Или отсортировать таблицу:

Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING);

Список некоторых действий с таблицей смотрите на скриншотах ниже:

Использование Masquerade значительно упростило написание тестов, теперь, чтобы написать тест для новой функциональности, нужно:

1. С помощью Masquerade описать страницу — это делается легко и не требует особых навыков программирования.
2. Собрать в одном классе все страницы, которые используются при проверке функционала.
3. Из готовых конструкций естественного языка собрать тестовый сценарий (подставив туда названия нужных элементов), то есть написать Gauge-спецификацию.

Интегрируем Masquerade и Gauge

До использования BDD, применялся подход TLD и для работы с ним мы также оптимизировали процесс написания кода тестов. Использовали связки jUnit/TestNG + WebDriver+Selenide+Masquerade.

Теперь, для того, что бы работать с Gauge, добавляем соответствующий плагин в intellij IDEA. После этого появится возможность создавать новый тип тестов — Specification.

Теперь создаем спецификацию (сценарий) и имплементируем шаги, используя возможности WebDriver, Masquerade и Java.

Кликаем на шаг сценария и переходим в имплементацию:

В имплементации можно использовать уже существующий метод login().

Как же выглядит это совершенство?

Вспомним пример, который мы рассматривали в самом начале статьи:

«Navigation.openMenu(menu)” содержит реализацию открытия меню с помощью библиотеки Masquerade.

Библиотека впоследствии была расширена и появились универсальные шаги, которые могут быть использованы для любого CUBA-приложения. Это шаги, позволяющие работать с элементами программы: кнопками, полями, таблицами. Эти универсальные шаги и стали тем набором стандартных фраз, которые мы используем в BDD для написания сценариев.

Благодаря связке Masquerade+Gauge мы существенно снизили трудоемкость создания тестов. Теперь тесты могут писать люди, не имеющие особых навыков программирования. Тест может писать один человек (раньше сценарий придумывал один, а реализовывал — другой, что приводило к путанице). Итак, мы добились своей цели — интерфейсы упрощены, а аналитикам не составит труда писать тестовые сценарии.

Изменения процесса изображены ниже:

Было:

Стало:

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

Итоги

На данный момент мы успешно ведем разработку по обозначенной выше схеме. И нам удалось избавиться от главной проблемы BDD — серьезного увеличения сроков из-за сложности реализации, добавив и доработав инструментарий. Однако, качество выдачи продуктов улучшилось.

Временные затраты на поддержку документации сокращаются пропорционально количеству измененных спецификаций, т.к. одно изменение спецификации (логики системы) приводит автоматически к изменению автотеста за одну итерацию. Т.е. тестировщику не нужно лезть в систему документации (типа Confluence и т.д) для апдейта, и для других участников команды это тоже справедливо.

Время на реализацию и поддержку тестов при наличии библиотеки, упрощающей работу с объектами страницы, уменьшилось в два раза, по сравнению с работой с обычным чистым web -driver и затратами на переделку ссылок XP.

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

В завершение, хотелось бы отметить, что данная схема разработки также интегрирована у нас с Continuous Integration и разработанной в нашей компании системой тест менеджмента — QA Lens. В QA Lens можно писать те же сценарии, что и в IDEA, используя предметно-ориентированный язык. Этот язык состоит из ранее составленного глоссария доступных действий, которые ранее имплементированы. При выполнении автотеста на Gauge с машины разработчика или CI — в QA Lens автоматически отмечается: какие шаги сценариев были пройдены, а какие нет. Таким образом, прогнав автотест сценария, написанного аналитиком, отдел тестирования сразу получает полную актуальную информацию о состоянии продукта.

Авторы: Сунагатов Ильдар и Юшкова Юлия (Yushkova)

• Cuba Platform
• BDD
• Masquerade
• Gauge
• Selenide
• Selenium WebDriver
• Управление тестированием
• Тестирование
• автотестирование
• java
• QA
• quality assurance
• autotesting
• Behaviour-Driven Development
• разработка через поведение
• agile
• software development
• разработка по

Behavior-Driven Development

Как правильно определять требования к продукту или системе, чтобы результаты разработки совпадали с ожиданиями.

Это именно то, о чем я просил, но не то, что я хочу

Поэма «Ночь перед воплощением», автор неизвестен

Разработка на основе поведения (Behavior-Driven Development, BDD) — это практика Agile-тестирования, когда в первую очередь проводятся проверочные испытания, которые обеспечивают встроенное качество за счет определения (и, потенциально, автоматизации) тестов до или как часть определения поведения системы. BDD — это совместный процесс, который создает общее понимание требований между бизнесом и Agile-командами. Его цель — помочь в управлении разработкой, уменьшить количество переделок и увеличить поток. Не фокусируясь на внутренней реализации, тесты BDD представляют собой бизнес-сценарии, которые пытаются описать поведение пользователя с точки зрения Истории (Story), Фичи (Feature) или Возможности (Capability).

Будучи автоматизированными, эти тесты гарантируют, что система постоянно соответствует заданному поведению даже в процессе своего развития. Это, в свою очередь, позволяет выпускать Релиз по Потребности (Release on Demand). Автоматизированные тесты BDD могут также служить для формулирования поведения системы, в качестве встроенной в другую систему.

Как определить будущее поведение системы

При разработке инновационных систем сложно точно определить, что именно нужно создать. Кроме того, новые идеи трудно донести до широкого круга заинтересованных лиц, ответственных за внедрение системы. На рис. 1 показаны три точки зрения (называемые триадой), необходимые, для четкого определения поведения решения:

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

Рис. 1. Разнообразие восприятий, необходимое для определения объективного принятия решения

Вместе эта группа достигает согласованности в том, что именно нужно создавать, чтобы уменьшить количество ошибок и переделок и ускорить поток ценностей.

Процесс поведенческой разработки

Процесс BDD проходит три этапа — исследование (discovery: раскрытие проблемы клиента и ее решения), формулирование и автоматизация — где критерии приемки преобразуются в приемочные испытания, которые затем автоматизируются. Процесс начинается на этапе исследования, когда Владелец Продукта (Product Owner, РО) или Менеджер Продукта (Product Manager, PM) создает критерии приемки как часть написания Истории или Фичи. Процесс исследования является совместным, и члены команды также определяют и вносят дополнительные критерии.

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

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

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

• поведенческая разработка (BDD);
• разработка на основе приемочных испытаний (Acceptance Test-Driven Development, ATDD);
• спецификация на примере (Specification By Example, SBE).

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

Пример

Описание поведения начинается с Истории, Фичи или Возможности, указанных в критериях приемки. Все они определяются с использованием клиентских терминов, а не внедрения. Вот пример истории и критерии ее принятия:

Рис. 2. Пример истории и критерии приёмки

Критерии приёмки также могут быть записаны в формате «Given — When — Then» (GWT), как показано ниже:

Given (Дано) ограничение скорости

When (Когда) машина едет

Then (Тогда) скорость близка к предельной, но не выше.

Даже в этом случае разработанных критериев приёмки обычно недостаточно, чтобы оформить Историю. Чтобы устранить неопределенность, сформулируйте сценарий в виде одного или нескольких примеров, которые определяют детали поведения, что приведет к конкретному приемочному тесту:

Дано ограничение скорости — 80 км/ч

Когда машина едет

Тогда её скорость — от 78 до 80 км/ч.

В сотрудничестве с командой (триадой) появятся дополнительные критерии приёмки и сценарии, например: когда ограничение скорости меняется, скорость резко не меняется.

Этот критерий приводит к дополнительным тестам, которые определяют допустимую интенсивность замедления:

Дано ограничение скорости составляет 80 км/ч

Когда ограничение скорости изменяется до 50 км/ч

Тогда скорость должна снижаться менее чем на 5 км/ч за сек.

На рис. 3 показан процесс BDD, который начинается с Истории и детализирует ее спецификацию в двух измерениях. По горизонтали дополнительные критерии приёмки детализируют требования к истории. По вертикали дополнительные приемочные тесты детализируют эти требования к приемочным тестам.

Рис. 3. Процесс BDD детализирует поведенческие характеристики.

Автоматизация приемочных тестов

Автоматизация этих бизнес-тестов является важной причиной по использованию формата «Дано — Когда — Тогда» (GWT — Given — When — Then). Для поддержки этого синтаксиса можно использовать такие инструменты как Cucumber и Framework for Integrated Testing (FIT) . Для поддержки тестирования регрессии непрерывной поставки тесты должны быть по возможности автоматизированы.

Приемочные тесты Истории пишутся и выполняются в той же итерации, что и разработка кода. Если История не проходит тесты, История не засчитывается команде. У Фич и возможностей есть свои собственные приемочные тесты, которые показывают, как несколько Историй работают вместе в более широком контексте. Как правило, эти тесты демонстрируют поведение более крупных сценариев рабочего процесса и должны выполняться во время итерации, в которой Фича или возможность завершены.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Behavior-Driven Development (BDD): что это

Как стать тестировщиком — путь к успеху

Unit тестирование в Java

Какие виды тестирования существуют

Понятие Agile тестирования в разработке ПО

End-to-End тестирование в деталях и примерах

Этот подход способствует лучшему пониманию требований, улучшает коммуникацию в команде и помогает автоматизировать тестирование.

BDD что это, какие преимущества данной методики, как начать работать и какие перспективы его использования — сегодня в материале отвечаем на эти вопросы.

Behavior-Driven Development (разработка, ориентированная на поведение), БДД — это такой подход к созданию программного обеспечения, который сосредоточен на том, как программа должна вести себя в конкретных ситуациях. Это как история, которую рассказывает программа, описывая свое поведение.

Главная идея БДД заключается в использовании языка, который понятен всем участникам проекта, будь то разработчики, тестировщики или заказчики. Мы создаем «сценарии» или «истории» о том, как программа должна вести себя в разных ситуациях. Это помогает всем понять, что именно ожидается от программы и как ее можно проверить.

В целом, БДД помогает команде разработчиков и другим заинтересованным сторонам лучше понять требования и ожидания, сотрудничать в процессе разработки и обеспечивать качество ПО.

Принципы и методы BDD

Принципы и методы BDD довольно просты и понятны, но давайте разберемся подробнее.

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

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

�� Начни свой путь в программировании с курсов Start Course! Без специальной подготовки!

Освой основы языка на выбор:

�� Java, Python, C#, JavaScript, C++, Swift

Цены от 1 225 грн / 40 USD. Получи доступ к видеолекциям и поддержке в Slack.

Выбирай свой язык и начинай! ����

Автоматизация тестирования — еще один важный аспект BDD. Мы пишем автоматизированные тесты на основе описанных сценариев. Эти тесты проверяют, выполняет ли программа описанное поведение. Автоматизация тестирования позволяет нам быстро и надежно проверить, работает ли программа так, как задумано, и обнаружить возможные проблемы.

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

Преимущества BDD

Использование BDD имеет несколько преимуществ:

• Лучшее понимание требований. BDD помогает команде разработчиков и заказчикам лучше понять требования к программному продукту. За счет описания поведения программы с использованием понятного языка и создания сценариев, все стороны могут получить четкое представление о том, как программа должна работать. Это снижает вероятность недоразумений и повышает качество согласования требований.

• Улучшенная коммуникация и сотрудничество. Вместо изолированного написания кода, разработчики, тестировщики и заказчики совместно работают над определением сценариев и написанием тестов. Это содействует лучшей коммуникации, обмену идеями и совместному решению проблем.

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

Похожие материалы
Как стать тестировщиком — путь к успеху
Unit тестирование в Java
Какие виды тестирования существуют
Понятие Agile тестирования в разработке ПО
End-to-End тестирование в деталях и примерах
Что такое BDD?

BDD — это подход разработки, который сосредотачивает внимание на поведении системы из перспективы пользователя.

В чем разница между BDD и TDD?

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

Какие инструменты используются для BDD?

Cucumber, SpecFlow, Behave и другие.

Зачем нужен BDD?

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

Может ли BDD заменить традиционное тестирование?

Нет, BDD — это дополнение к другим методам тестирования. Он помогает в определении критериев приемки, но не заменяет другие формы тестирования.

Каковы главные преимущества и недостатки BDD?

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