Бддс пример: Отчет БДДС (бюджет движения денежных средств) по текущей деятельности

Содержание

Что такое тестирование BDD? Пример платформы

Что такое тестирование BDD (разработка, управляемая поведением)?

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

 

Как работает тестирование BDD?

Учтите, что вам поручено создать модуль перевода средств в приложении Net Banking.

Есть несколько способов проверить это

  1. Перевод средств должен осуществляться при наличии достаточного остатка на исходном счете

    2. .

  2. Денежный перевод должен быть осуществлен, если реквизиты пункта назначения указаны верно
  3. Перевод средств должен выполняться, если пароль транзакции / код rsa / аутентификация безопасности для транзакции, введенной пользователем, верны
  4. Перевод средств должен осуществляться, даже если это выходной день

    5. .

  5. Перевод средств должен быть осуществлен в будущую дату, установленную владельцем счета

Сценарий тестирования становится более детальным и сложным, поскольку мы рассматриваем дополнительные функции, такие как сумма перевода X за интервал Y дней/месяцев, остановка графика перевода, когда общая сумма достигает Z и т. д.

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

Чтобы решить эту проблему (разработка, основанная на поведении), был задуман BDD. Это упрощает весь процесс тестирования для разработчика.

В BDD все, что вы пишете, должно состоять из заданных-когда-то шагов. Давайте рассмотрим тот же пример выше в BDD

  Учитывая , что модуль перевода средств в приложении сетевого банковского обслуживания был разработан
И я получаю к нему доступ с надлежащей аутентификацией 
  Когда  я переведу с достаточным балансом в моей исходной учетной записи
Или я переведу в выходной день
Или я перенесу на будущую дату
И информация о пункте назначения верна
И пароль транзакции/код rsa/аутентификация безопасности для транзакции верны
И нажмите или нажмите кнопку отправки 
  Затем необходимо перевести  сумму
И событие будет зарегистрировано в файле журнала

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

Что такое тестирование REST API?

Поскольку в настоящее время REST стал довольно популярным стилем для создания API, не менее важной стала автоматизация тестовых случаев REST API наряду с тестовыми примерами пользовательского интерфейса. Таким образом, в основном это тестирование REST API включает в себя тестирование действий CRUD (Create-Read-Update-Delete) с методами POST, GET, PUT и DELETE соответственно.

Что такое поведение?

Behave — одна из популярных сред тестирования Python BDD.

Давайте посмотрим, как работает функция Behave:

Файлы функций написаны вашим бизнес-аналитиком / спонсором / кем-то еще с вашими сценариями поведения. Он имеет формат естественного языка, описывающий функцию или часть функции с репрезентативными примерами ожидаемых результатов.

Эти шаги сценария сопоставлены с реализациями шагов, написанными на Python.

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

Давайте начнем с настройки нашей платформы тестирования автоматизации с помощью Behave:

Настройка BDD Testing Framework Behave в Windows

Установка:

  • Загрузите и установите Python 3 с https://www.python.org/
  • Выполните следующую команду в командной строке, чтобы установить поведение
  • pip устанавливает поведение
  • IDE: я использовал PyCharm Community Edition https://www.jetbrains.com/pycharm/download

Настройка проекта:

  • Создать новый проект
  • Создайте следующую структуру каталогов:

Файлы функций:

Итак, давайте создадим наш файл функций Sample_REST_API_Testing.feature с функцией Выполнение операций CRUD в службе «сообщения».

В нашем примере я использовал http://jsonplaceholder.typicode.com/ posts образец службы REST.

Пример сценария POST 

 Сценарий: Пример сообщения POST -> Здесь мы рассматриваем возможность создания нового элемента сообщения с использованием службы «сообщения». 
Дано: я устанавливаю конечную точку API сообщений для сообщений -> Это обязательное условие для теста, который устанавливает URL-адрес службы сообщений.
Когда: я установил тип содержимого запроса параметра HEADER как «application/json».
И установить тело запроса
И отправьте HTTP-запрос POST -> Это фактический тестовый шаг отправки почтового запроса.
Тогда: Затем я получаю действительный код ответа HTTP 201
И тело ответа "POST" не пусто-> Это проверка тела ответа

Аналогичным образом вы можете написать оставшиеся сценарии следующим образом:

Sample_REST_API_Testing.feature 

 Функция: тестирование методов CRUD в тестовой среде Sample REST API
Фон:
Учитывая, что я установил образец URL-адреса REST API
Сценарий: пример сообщения POST
  Учитывая, что я установил конечную точку API для сообщений POST
 Когда я устанавливаю тип содержимого запроса параметра HEADER как «application/json».
    И установить тело запроса
 И отправьте HTTP-запрос POST
 Затем я получаю действительный код ответа HTTP 201
    И тело ответа "POST" не пусто. 
Сценарий: пример сообщений GET
  Учитывая, что я установил конечную точку API GET сообщений "1"
  Когда я устанавливаю тип содержимого запроса параметра HEADER как «application/json».
И отправить запрос GET HTTP
  Затем я получаю действительный код ответа HTTP 200 для «GET».
И ответ BODY "GET" не пуст.
Сценарий: пример сообщений UPDATE
  Учитывая, что я установил конечную точку API сообщений PUT для «1»
  Когда я устанавливаю тело запроса на обновление
И отправить HTTP-запрос PUT
  Затем я получаю действительный код ответа HTTP 200 для «PUT».
И ответ BODY "PUT" не пуст.
Сценарий: пример УДАЛЕНИЯ сообщений
  Учитывая, что я установил конечную точку API сообщений DELETE для «1»
  Когда я отправляю HTTP-запрос DELETE
  Затем я получаю действительный код ответа HTTP 200 для «УДАЛИТЬ».

Реализация шагов

Теперь для функций Steps, используемых в описанных выше сценариях, вы можете писать реализации в файлах Python в каталоге «steps».

Инфраструктура поведения идентифицирует функцию Step с помощью декораторов, соответствующих предикату файла функций. Например, предикат Given в файле Feature Scenario ищет пошаговую функцию, имеющую декоратор «данный». Аналогичное сопоставление происходит для When и Then. Но в случае «Но», «И», функция шага принимает декоратор так же, как и предыдущий шаг. Например, если вместо «Дано» стоит «И», декоратором соответствующей пошаговой функции будет @дано.

Например, когда шаг для POST может быть реализован следующим образом:

 @when (u'I Установить тип содержимого запроса параметра HEADER как "{header_conent_type}"')
Сопоставление Когда, здесь уведомление «application/json» было передано из файла функций для «{header_conent_type}». Это называется параметризацией
def step_impl (контекст, header_conent_type):
Это сигнатура метода реализации шага
request_headers['Content-Type'] = header_conent_type
Код реализации шага, здесь вы будете устанавливать тип контента для заголовка запроса

Аналогично, реализация других шагов в файле шага python будет выглядеть так:

sample_step_implementation.

py

запросы на импорт
api_endpoints = {}
request_headers = {}
код_ответа = {}
ответ_тексты={}
запрос_боди = {}
api_url = нет
@given(u'I установил образец URL-адреса REST API')
def step_impl (контекст):
    глобальный API_url
    api_url = 'http://jsonplaceholder.typicode.com'
# НАЧАТЬ Сценарий POST
@given(u'I устанавливаю конечную точку API сообщений POST')
def step_impl (контекст):
    api_endpoints['POST_URL'] = api_url+'/сообщения'
    print('url:'+api_endpoints['POST_URL'])
@when(u'I Установить тип содержимого запроса параметра HEADER как "{header_conent_type}"')
def step_impl (контекст, header_conent_type):
    request_headers['Content-Type'] = header_conent_type
# Вы также можете включить «И» или «Но» в качестве шага — они переименовываются по поведению, чтобы взять имя предыдущего шага, поэтому:
@when(u'Установить тело запроса')
def step_impl (контекст):
    request_bodies['POST']={"title": "foo","body": "bar","userId": "1"}
# Вы также можете включить «И» или «Но» в качестве шага — они переименовываются по поведению, чтобы взять имя предыдущего шага, поэтому:
@when(u'Отправить HTTP-запрос POST')
def step_impl (контекст):
    # отправка запроса на получение и сохранение ответа в качестве объекта ответа
    response = request. post(url=api_endpoints['POST_URL'], json=request_body['POST'], headers=request_headers)
    #response = request.post(url=api_endpoints['POST_URL'], headers=request_headers) #https://jsonplaceholder.typicode.com/posts
    # извлечение текста ответа
    response_texts['POST']=ответ.текст
    print("Ответ на публикацию:"+response.text)
    # извлечение ответа status_code
    код состояния = response.status_code
    response_codes['POST'] = код состояния
@then(u'Я получаю действительный код ответа HTTP 201')
def step_impl (контекст):
    print('Код представителя сообщения ;'+str(response_codes['POST']))
    утвердить response_codes['POST'] 201
# Сценарий END POST
# НАЧАТЬ ПОЛУЧИТЬ Сценарий
@given(u'I установил конечную точку GET для сообщений API "{id}"')
def step_impl (контекст, идентификатор):
    api_endpoints['GET_URL'] = api_url+'/сообщения/'+id
    print('url:'+api_endpoints['GET_URL'])
# Вы также можете включить «И» или «Но» в качестве шага — они переименовываются по поведению, чтобы взять имя предыдущего шага, поэтому:
@when(u'Отправить HTTP-запрос GET')
def step_impl (контекст):
    # отправка запроса на получение и сохранение ответа в качестве объекта ответа
    response = request. get(url=api_endpoints['GET_URL'], headers=request_headers) #https://jsonplaceholder.typicode.com/posts
    # извлечение текста ответа
    response_texts['GET']=ответ.текст
    # извлечение ответа status_code
    код состояния = response.status_code
    response_codes['GET'] = код состояния
@then(u'Я получаю действительный код ответа HTTP 200 для "{request_name}"')
def step_impl (контекст, имя_запроса):
    print('Получить код представителя для '+request_name+':'+ str(response_codes[request_name]))
    утвердить response_codes[имя_запроса] равно 200
@then(u'Response BODY "{request_name}" непусто')
def step_impl (контекст, имя_запроса):
    print('имя_запроса: '+имя_запроса)
    печать (response_texts)
    утверждать, что response_texts[request_name] не равно None
# КОНЕЦ ПОЛУЧИТЬ Сценарий
# НАЧНИТЕ ПОСТАВЛЯТЬ/ОБНОВЛЯТЬ
@given(u'I установил конечную точку API PUT для "{id}"')
def step_impl (контекст, идентификатор):
    api_endpoints['PUT_URL'] = api_url + '/posts/'+id
    print('url:' + API_endpoints['PUT_URL'])
@when(u'Я установил тело запроса на обновление')
def step_impl (контекст):
    request_bodies['PUT']={"title": "foo","body": "bar","userId": "1","id": "1"}
@when(u'Отправить HTTP-запрос PUT')
def step_impl (контекст):
    # отправка запроса на получение и сохранение ответа в качестве объекта ответа # response = request. post(url=api_endpoints['POST_URL'], headers=request_headers) #https://jsonplaceholder.typicode.com/posts
    response = request.put(url=api_endpoints['PUT_URL'], json=request_body['PUT'], headers=request_headers)
    # извлечение текста ответа
    response_texts['PUT'] = ответ.текст
    print("обновить ответ:" + response.text)
    # извлечение ответа status_code
    код состояния = response.status_code
    response_codes['PUT'] = код состояния
#КОНЕЦ ВСТАВКИ/ОБНОВЛЕНИЯ
#СТАРТ УДАЛИТЬ
@given(u'I установил конечную точку API DELETE для "{id}"')
def step_impl (контекст, идентификатор):
    api_endpoints['DELETE_URL'] = api_url + '/posts/'+id
    print('url:' + API_endpoints['DELETE_URL'])
@when(u'Я отправляю HTTP-запрос DELETE')
def step_impl (контекст):
    # отправка запроса на получение и сохранение ответа в качестве объекта ответа
    ответ = запросы.удалить(url=api_endpoints['DELETE_URL'])
    # response = request.post(url=api_endpoints['POST_URL'], headers=request_headers) #https://jsonplaceholder. typicode.com/posts
    # извлечение текста ответа
    response_texts['DELETE'] = ответ.текст
    print("УДАЛИТЬ ответ:" + response.text)
    # извлечение ответа status_code
    код состояния = response.status_code
    response_codes['DELETE'] = код состояния
#КОНЕЦ УДАЛИТЬ

Запуск тестов

Теперь мы закончили с нашей частью разработки тестового сценария, поэтому давайте запустим наши тесты:

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

C:\Programs\Python\Python37> поведения -f довольно C:\<ваш путь к проекту>\features\feature_files_folder\ Sample_REST_API_Testing.feature

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

Отображение отчета на консоли

Давайте посмотрим еще одну интересную вещь.

Так как пользователи всегда предпочитают видеть результаты тестов в более читабельном и презентабельном формате, давайте с помощью Allure иметь отчеты в формате HTML.

Отчеты

Сначала необходимо установить средство форматирования Allure Behave [https://docs.qameta.io/allure-report/]:

А теперь выполните следующую команду:

Для отчетов

> поведения — f json -o <путь к папке с вашим отчетом> Sample_REST_API_Testing.feature

<путь к папке allure-bin>> allure serve <путь к папке с вашим отчетом>

Это создаст отчет о результатах тестирования в презентабельном и информативном формате, например:

Отчет о тестировании в формате HTML

Отчет о тестировании, отображающий результат отдельного сценария

Резюме:

  • BDD — это разработка, основанная на поведении. Это один из методов гибкой разработки программного обеспечения.
  • В настоящее время REST стал довольно популярным стилем для создания API, стало не менее важным автоматизировать тестовые примеры REST API наряду с тестовыми примерами пользовательского интерфейса.
  • BDD имеет формат естественного языка, описывающий функцию или часть функции с репрезентативными примерами ожидаемых результатов
  • Инфраструктура поведения идентифицирует функцию Step с помощью декораторов, соответствующих предикату файла функций

    • .

  • Примеры сред тестирования BDD: 1) Cucumber 2) SpecFlow 3) Quantum 4) JBehave 5) Codeception

Полное руководство по разработке, ориентированной на поведение (BDD)

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

Содержание

  • Что такое BDD (разработка, основанная на поведении)?
  • Процесс разработки, основанный на поведении
  • Примеры разработки, основанной на поведении

Что такое BDD (развитие, управляемое поведением)?

BDD (разработка, ориентированная на поведение) — это процесс разработки программного обеспечения, основанный на методологии Agile. Концепция разработки, ориентированной на поведение, возникла из подхода разработки через тестирование (TDD). Этот процесс разработки программного обеспечения ориентирован на требования конечных пользователей и их взаимодействие с продуктом.

Объяснение процесса BDD

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

Разработка на основе поведения — это очень востребованная методология разработки программного обеспечения, используемая для разработки разнообразных приложений для различных секторов, от B2B до SaaS. Разработка, основанная на поведении, основана на трех столпах: обнаружение, формулировка и автоматизация.

Давайте посмотрим, почему разработка на основе поведения так популярна среди разработчиков и тестировщиков.

Основные преимущества BDD

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

Основные преимущества BDD

Помимо этого, существуют и другие преимущества, перечисленные ниже:

1. Разработка продукта, ориентированная на клиента

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

2. Правильное определение приоритетов функций

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

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

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

3. Большая прозрачность

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

4. Снижение риска обслуживания и проекта

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

5. Лучшее согласование с общими бизнес-целями

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

См. также: 10 лучших инструментов для тестирования на проникновение в 2022 году

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

Процесс разработки, основанный на поведении, основан на трех важнейших подходах:

1.

Тестовый подход 9 0075

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

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

2. Гибкий подход к тестированию

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

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

3. Встроенный подход к качеству

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

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

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

1. Фаза открытия

Фаза открытия — это первая фаза разработки, основанной на поведении, на которой исследуются и определяются критерии приемлемости. Как правило, менеджер по продукту активно участвует в фазе исследования разработки, основанной на поведении.

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

2. Фаза формулировки

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

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

3. Этап автоматизации

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

Узнать больше: Что такое тестирование на проникновение? Типы, методы и рекомендации

Примеры разработки на основе поведения

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

1. BDD с синтаксисом Gherkin

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

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

  • Функция: Используется для описания функции программного обеспечения.
  • Сценарий: Обозначает поведение системы. Сценарий описывает различные шаблоны, такие как события, требуемые результаты, исходный контекст и другие.
  • Фон: Фон относится к контексту и фону системы с определенным набором функций и решений.
  • Схема сценария: Схема сценария подразумевает схему поведения системы, особенно в случае нескольких сценариев.
  • Примеры: Примеры обозначают различные факторы, относящиеся к BDD, такие как функции, решения, функции и другие.
  • Дано, Когда, Тогда и Но (Шаги): Они обозначают различные шаги, условия и отношения между шагами.
  • «»» (Строки документов): Обозначает строки документов.
  • | (Таблицы данных): Представляет данные, хранящиеся в таблицах.
  • @ (Tags): Они относятся к различным элементам процесса разработки, основанного на поведении.
  • # (Комментарии): Комментарии передают важную и дополнительную информацию, относящуюся к программированию, управляемому поведением.

2. BDD с Cucumber

Еще один яркий пример BDD можно увидеть с помощью среды тестирования CucumberOpens a new window