На протяжении истории люди придумывали различные подходы и приёмы, как разрабатывать более качественные и поддерживаемые приложения. В этой статье я бы хотел рассказать о такой методологии разработки, как BDD (Behaviour Driven Development). Но прежде чем перейти непосредственно к гвоздю программы — небольшое вступление.

Думаю, большинство разработчиков согласятся с мыслью о том, что покрытый юнит-тестами код лучше, чем непокрытый. Действительно, тесты позволяют эффективно следить за работоспособностью кода, вовремя отлавливать нерабочие изменения. А ещё из наличия юнитов обычно следует то, что код разбит на логические модули и каждый класс/функция имеет одну зону ответственности (привет SOLID). Тот, кому доводилось писать тест на большую функцию с несколькими зонами ответственности знает, что тесты на такую функцию обречены быть хрупкими и падать при малейшем изменении. Это заставляет задуматься о том, чтобы не писать всё "в одной портянке", а писать гибкий код, поделённый на модули. С таким кодом, как правило, приятнее работать, т.к. приходится держать в уме меньше информации.

В какой-то момент люди сделали вывод, что раз код хороший если он тестируемый, тогда давайте мы сначала напишем тесты на этот код, а уже потом сам код. И так придумали методологию...

Test Driven Development (TDD)

Test Driven Development (TDD) — это подход к разработке программного обеспечения, который ставит тестирование на первое место. В TDD разработчики сначала пишут тесты для новой функциональности, а затем пишут код, который позволит этим тестам пройти. Это отличается от традиционного подхода, когда тесты пишутся после кода, однако привносит свои преимущества:

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

• Упрощение рефакторинга: Тесты служат "сетью безопасности", позволяя разработчикам вносить изменения в код без страха сломать что-то.

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

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

Конечно, за всё приходится платить, и TDD не является исключением:

• Замедление процесса разработки: Написание тестов занимает время, которое могло бы быть потрачено на написание нового кода.

• Трудность написания хороших тестов: Написание эффективных тестов — это навык, который требует практики и опыта.

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

Behavior Driven Development как развитие TDD

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

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

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

Принципы BDD

BDD основывается на нескольких ключевых принципах:

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

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

3. Сотрудничество и коммуникация: BDD подчеркивает важность сотрудничества и общения между всеми участниками команды. Это помогает обеспечить общее понимание целей и требований проекта.

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

Как и любой подход, BDD имеет свои преимущества и недостатки.

Плюсы:

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

2. Сосредоточение на бизнес-целях: BDD помогает команде сосредоточиться на достижении конкретных бизнес-целей, а не просто на написании кода.

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

Минусы:

1. Сложность внедрения: Внедрение BDD может потребовать значительных изменений в процессах разработки и тестирования, что может быть сложно для некоторых команд.

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

3. Риск неправильного понимания: Если сценарии BDD написаны неправильно или нечетко, это может привести к неправильному пониманию требований или ожидаемого поведения системы.

При разработке BDD тестов можно использовать два подхода:

1. Тест-кейсы и реализация степов на классическом ЯП.
   Сами тесты должны выглядеть максимально понятно и не содержать сложной логики. Условный BDD-тест на Python может выглядеть так:

   class FeatureCalculator:
       """
       As a user
       I want to perform some math ops
       """
   
       def test_one_plus_one(self):
           """
           I can successfully add one to one
           """
           # Given
           self.working_calculator()
           # When
           self.i_add(1, 1)
           # Then
           self.result_is(2)
   
       def test_one_plus_one_broken_calculator(self):
           """
           I try to add one to one using broken calculator
           """
           # Given
           self.broken_calculator()
           # When
           self.i_add(1, 1)
           # Then
           self.result_is(None)
   
       def working_calculator(self):
           ...
   
       def broken_calculator(self):
           ...
   
       def i_add(self, x, y):
           ...
   
       def result_is(self, x):
           ...
   

2. Тест-кейсы на Gherkin, реализация степов на классическом ЯП. 
   Gherkin — это язык, созданный специально для описания поведения систем. Содержит небольшое количество ключевых слов, которое тем не менее является достаточным для составления тестовых сценариев. Тот же самый тест, но на Gherkin:

   Feature: Calculator
     As a user
     I want to perform some math ops
   
     Scenario: I can successfully add one to one
       Given working calculator
        When I add 1 to 1
        Then result is 2
   
     Scenario: I try to add one to one using broken calculator
       Given broken calculator
        When I add 1 to 1
        Then result is None

Практическая часть: Примеры BDD тестов с использованием библиотеки python-behave

Для практики давайте покроем BDD тестами некоторое приложение. На SwaggerHub выложен в открытом доступе Swagger Petstore — REST API для управления неким "магазином домашних питомцев". Попробуем покрыть тестами endpoint POST /pet, отвечающий за добавление нового питомца в магазин.

Писать тесты я буду с использованием Gherkin. Для реализации таких тестов я выбрал Python 3.10 + фреймворк python-behave. Установить его можно через pip:

pip install behave

Впрочем, BDD фреймворков существует много для таких языков как Java, C#, Go, JavaScript и другие.

Запуск BDD тестов происходит через консоль командой behave, либо через плагины для вашего любимого инструмента разработки (например в PyCharm Professional поддержка BDD есть из коробки).

Примеры BDD тестов

Создадим новый feature-файл:

features/pet.feature

Feature: Everything about your Pets
  As user I want to add, update, and delete pets in the pet store

  # здесь будут располагаться тесты
  # Scenario: ...

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

features/pet.feature

  Scenario: I successfully create new empty pet
    When I make POST request to "/pet" with body
    Then Response is 200

Но этот тест не запустится прямо сейчас, потому что мы не реализовали поведение для шагов I make POST request to "/pet" with body и Response is 200:

Feature: Everything about your Pets # features/pet.feature:1
  As user I want to add, update, and delete pets in the pet store
  Scenario: I successfully create new empty pet  # features/pet.feature:4
    When I make POST request to "/pet" with body # None
    Then Response is 200                         # None


Failing scenarios:
  features/pet.feature:4  I successfully create new empty pet

0 features passed, 1 failed, 0 skipped
0 scenarios passed, 1 failed, 0 skipped
0 steps passed, 0 failed, 0 skipped, 2 undefined
Took 0m0.000s

You can implement step definitions for undefined steps with these snippets:

@when(u'I make POST request to "/pet" with body')
def step_impl(context):
    raise NotImplementedError(u'STEP: When I make POST request to "/pet" with body')


@then(u'Response is 200')
def step_impl(context):
    raise NotImplementedError(u'STEP: Then Response is 200')

Давайте это исправим:

features/steps/pet.py

import json

import requests
from behave import step

ROOT_URL = r"https://petstore.swagger.io/v2"


@step('I make POST request to "{path}" with body')
def make_post_request_step(context, path):
    body = json.loads(context.text or "{}")
    url = ROOT_URL + path
    context.response = requests.post(url, json=body)


@step("Response is {status_code:d}")
def assert_response_step(context, status_code):
    assert (
        context.response.status_code == status_code,
        f"Expected {status_code}, got {context.response.status_code}"
    )

Попробуем запустить ещё раз:

Feature: Everything about your Pets # features/pet.feature:1
  As user I want to add, update, and delete pets in the pet store
  Scenario: I successfully create new empty pet  # features/pet.feature:4
    When I make POST request to "/pet" with body # features/steps/pet.py:9
    Then Response is 200                         # features/steps/pet.py:17

1 feature passed, 0 failed, 0 skipped
1 scenario passed, 0 failed, 0 skipped
2 steps passed, 0 failed, 0 skipped, 0 undefined
Took 0m0.927s

Удостоверимся, что тест работает, немного поломав его. Пусть мы будем ожидать ответ 300 вместо 200:

Feature: Everything about your Pets # features/pet.feature:1
  As user I want to add, update, and delete pets in the pet store
  Scenario: I successfully create new empty pet  # features/pet.feature:4
    When I make POST request to "/pet" with body # features/steps/pet.py:9
    Then Response is 300                         # features/steps/pet.py:17
      Assertion Failed: Expected 300, got 200


Failing scenarios:
  features/pet.feature:4  I successfully create new empty pet

0 features passed, 1 failed, 0 skipped
0 scenarios passed, 1 failed, 0 skipped
1 step passed, 1 failed, 0 skipped, 0 undefined
Took 0m1.026s

Замечательно! Теперь при помощи этих шагов можно написать и негативные сценарии:

features/pet.feature

  Scenario: I get an error if I try to create a pet with invalid category id
    When I make POST request to "/pet" with body
      """
      {
        "category": {"id": "zero", "name": "cats"}
      }
      """
    Then Response is 500

  Scenario: I get an error if I try to create a pet with invalid tag id
    When I make POST request to "/pet" with body
      """      {
        "tags": {"id": "zero", "name": "puffy"}
      }
      """
    Then Response is 500

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

feature/steps/pet.py

def has_json_response(context) -> bool:
    try:
        context.response.json()
        return True
    except ValueError or AttributeError:
        return False


@step("Response contains json with items")
def assert_response_contains_json(context):
    assert (
        has_json_response(context),
        f"Expected json, but got {context.response.text}"
    )
    actual_values = context.response.json()
    expected_values = json.loads(context.text)
    for field in expected_values:
        expected_value = expected_values[field]
        actual_value = actual_values[field]
        match expected_value:
            case "<{any_int}>":
                assert (
                    isinstance(actual_value, int),
                    f'Expected "{field}" is a number value, got {actual_value}'
                )
            case _:
                assert (
                    expected_value == actual_value,
                    f'Expected "{field}" equals {expected_value}, got {actual_value}'
                )

Рассмотрев внимательнее реализацию этого степа, можно заметить, что он может делать две вещи:

• проверка на равенство значений, если в качестве ожидаемого значения указать число

• проверка на принадлежность значения множеству целых чисел, если в качестве ожидаемого значения указать строку <{any_int}>

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

Обновим первый тест:

features/pet.feature

  Scenario: I successfully create new empty pet
    When I make POST request to "/pet" with body
    Then Response is 200
     And Response contains json with items
      """
      {
        "id": "<{any_int}>",
        "tags": [],
        "photoUrls": []
      }
      """

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

features/pet.feature

  Scenario Outline: I successfully create new pet with specified name, category, status, tags and photo
    When I make POST request to "/pet" with body
      """
      {
        "name": "Barsik",
        "category": {"name": "cats"},
        "status": "<category>",
        "tags": [
          {"name": "puffy"},
          {"name": "young"}
        ]
      }
      """
    Then Response is 200
     And Response contains json with items
      """
      {
        "id": "<{any_int}>",
        "name": "Barsik",
        "category": {"id": 0, "name": "cats"},
        "status": "<category>",
        "tags": [
          {"id": 0, "name": "puffy"},
          {"id": 0, "name": "young"}
        ],
        "photoUrls": []
      }
      """

    Examples:
      | category  |
      | available |
      | pending   |
      | sold      |

Полностью проект доступен по ссылке: github.com/rmksrv/swaggerhub-petstore-bdd

Заключение

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

Материал был написан в феврале 2024-го года на основании опыта, полученного во время работы в ООО «Аурига».

Надеюсь, что статья была интересной и благодарю за внимание!