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

Разница между TDD и BDD: философия, подход и практика

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

Ключевые различия в концепции и фокусе

• Философия TDD: Это техническая практика для разработчиков, сфокусированная на проектировании кода и его корректности на уровне модулей (юнитов). Девиз: "Красный -> Зеленый -> Рефакторинг". Основная цель — создание чистого, рабочего и проверяемого кода. Тесты в TDD являются спецификацией реализации.
• Философия BDD: Это практика совместной работы, которая фокусируется на поведении системы с точки зрения бизнеса и пользователя. Девиз: "Зачем?". Цель — обеспечить понимание того, что должна делать система и почему это важно, для всех участников процесса (менеджеры, аналитики, тестировщики, разработчики). Сценарии в BDD являются живой документацией и спецификацией поведения.

Процесс и структура

Процесс TDD (классический цикл):

1. Написание падающего юнит-теста для новой небольшой функциональности.
2. Написание минимального кода, чтобы тест прошёл.
3. Рефакторинг кода (и тестов) для улучшения структуры.

Пример кода TDD (Python/pytest):

# 1. Пишем падающий тест (красный)
def test_calculate_discount():
    cart = ShoppingCart()
    cart.add_item("Book", 100)
    assert cart.calculate_discount(10) == 90  # Метод calculate_discount ещё не существует

# 2. Пишем минимальную реализацию (зелёный)
class ShoppingCart:
    def calculate_discount(self, percent):
        total = sum(item['price'] for item in self.items)
        return total * (1 - percent/100)

# 3. Рефакторим (например, улучшаем читаемость)

Процесс BDD (на основе Gherkin):

1. Совместное обсуждение и формулировка сценариев поведения на естественном языке (Gherkin).
2. Автоматизация этих сценариев в виде сквозных (end-to-end) или интеграционных тестов.
3. Реализация функциональности, которая делает сценарии проходящими.

Пример сценария BDD (Gherkin):

# Это спецификация поведения, понятная всем
Функция: Расчет скидки для покупателя
  Чтобы поощрять лояльных клиентов
  Как владелец магазина
  Я хочу применять скидку к корзине

  Сценарий: Применение скидки 10% к корзине с товарами
    Дано у меня есть корзина с товаром "Книга" ценой 100 руб
    Когда я применяю скидку 10 процентов
    Тогда итоговая сумма к оплате должна быть 90 руб

Критические отличия в таблице

Синергия TDD и BDD в проекте

Важно понимать, что это не взаимоисключающие, а дополняющие практики. Их часто используют вместе в рамках одного проекта ("золотая пирамида тестирования"):

• BDD работает на верхнем уровне (уровень бизнеса), описывая ключевые сценарии и формируя "скелет" автоматизации. Эти тесты, как правило, медленные и проверяют систему целиком.
• TDD работает на нижнем уровне (уровень кода), обеспечивая надежность и качество отдельных компонентов, из которых состоит система. Эти тесты быстрые и изолированные.

Идеальный поток: Команда использует BDD-сценарии для определения и автоматизации критически важного поведения системы (что даёт уверенность, что система работает правильно с точки зрения пользователя). Затем разработчики, реализуя фичу, используют TDD для создания внутренних модулей, что обеспечивает надежную и гибкую архитектуру. Таким образом, BDD задает направление "что строить", а TDD определяет "как строить качественно".