Перейти к основному содержимому

Unit, Integration, UI, E2E, TDD и BDD

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Тестировщику Разработчику Аналитику

Зачем эта статья. Частая путаница: Unit/Integration/UI/E2E смешивают с TDD/BDD. Уровни тестирования отвечают на вопрос что проверяем, а TDD/BDD - как организуем работу и формулируем требования.

Главное различие: уровни и практики​

  • Unit / Integration / UI / E2E - уровни тестирования (объект проверки и глубина охвата).
  • TDD / BDD - практики разработки и коммуникации (процесс формулирования и проверки поведения).

Коротко: Unit и Integration - это не альтернатива TDD/BDD. Можно делать unit-тесты без TDD. Можно вести BDD-сценарии и запускать их как API/integration или как E2E через UI.

Unit, Integration, UI, E2E - что и зачем​

Unit​

Проверяем маленький фрагмент логики в изоляции: функцию, метод, класс.

  • быстрые (миллисекунды);
  • много штук;
  • хорошо ловят ошибки алгоритмов и условий;
  • плохо ловят проблемы интеграции между сервисами.

Подробнее: Юнит-тестирование.

Integration​

Проверяем стык компонентов: сервис + БД, сервис + внешний API, очередь + обработчик.

  • медленнее unit;
  • ловят рассинхрон контрактов и ошибки сериализации;
  • особенно важны в микросервисах и API-heavy продуктах.

Подробнее: Интеграционное тестирование, Тестирование и анализ API.

UI​

Проверяем поведение интерфейса: элементы, валидации, состояния, рендер, доступность.

  • часто автоматизируются отдельно от полного бизнес-пути;
  • могут работать с моками бэкенда;
  • полезны для проверки фронтенд-логики и UX-критичных узлов.

Подробнее: End-to-End и системное тестирование, Ручное тестирование веба.

E2E​

Проверяем сквозной пользовательский сценарий через всю систему: UI -> backend -> БД -> внешние зависимости.

  • самые дорогие и хрупкие;
  • критичны для проверки P0/P1 потоков (логин, оплата, оформление);
  • должны быть в малом количестве, но точными по бизнес-ценности.

Подробнее: End-to-End и системное тестирование.

Практическая матрица выбора​

ВопросЧто запускать первымПочему
Сломалась формула расчета скидкиUnitБыстро и точно локализует логику
После рефакторинга API приходят пустые поляIntegration/APIПроверяет контракт и сериализацию
Кнопка "Оплатить" неактивна на формеUIПроблема на уровне интерфейса
Пользователь не может завершить покупкуE2EНужно проверить полный путь с зависимостями

Рабочая стратегия: максимум проверок опускаем вниз (Unit, Integration/API), наверху (UI/E2E) держим только критичные пути.

TDD: разработка через тест​

TDD (Test-Driven Development) - это цикл:

  1. Red - пишем тест на ожидаемое поведение, тест падает.
  2. Green - пишем минимальный код, чтобы тест прошел.
  3. Refactor - улучшаем код без изменения поведения.

Что дает TDD:

  • более четкие контракты кода;
  • меньше "лишней" реализации;
  • безопасный рефакторинг;
  • быстрый feedback в разработке.

Где особенно полезно:

  • бизнес-правила и расчетные модули;
  • библиотеки и SDK;
  • сложные преобразования данных.

Ограничение: TDD не отменяет integration и E2E. Он делает фундамент (unit) надежнее.

Практика

Пошаговый мини-кейс с циклом Red-Green-Refactor на Python — "Тренируем Test-Driven Development". Связь TDD с методологиями (Agile, XP) — раздел "Методология и жизненный цикл ПО".

BDD: поведение как спецификация​

BDD (Behavior-Driven Development) помогает согласовать требования между бизнесом, аналитикой, QA и разработкой через язык поведения системы.

Часто используется формат Given/When/Then:

Feature: Оформление заказа

Scenario: Успешная оплата картой
  Given пользователь авторизован и в корзине есть товар
  When он оплачивает заказ валидной картой
  Then заказ получает статус "Оплачен"
  And пользователь видит страницу подтверждения

Что дает BDD:

  • одинаковое понимание требований до разработки;
  • живую документацию;
  • прозрачную связь "бизнес-требование -> автотест".

Важно: BDD - это не только .feature файлы и Cucumber. Суть в совместной формулировке поведения.

Как TDD и BDD сочетаются с уровнями тестов​

  • TDD + Unit: классическая связка для разработки внутренней логики.
  • BDD + Integration/API: проверка бизнес-правил через контракты сервисов.
  • BDD + E2E/UI: критические пользовательские сценарии на языке бизнеса.

Одна и та же фича обычно имеет несколько слоев:

  • unit-проверки на уровне кода;
  • integration/API на уровне контрактов;
  • 1-2 E2E-сценария на бизнес-путь.

Частые ошибки и как их избежать​

  • Ошибка: "Покроем все UI-тестами".
    Как лучше: основную массу регресса держать в unit/integration, UI/E2E - только для критичных потоков.

  • Ошибка: "У нас есть unit, значит E2E не нужны".
    Как лучше: оставить короткий smoke-набор E2E для проверки сквозной сборки.

  • Ошибка: "BDD = писать шаги на английском".
    Как лучше: сначала договориться о поведении и критериях приемки, инструмент вторичен.

  • Ошибка: "TDD обязателен для каждого модуля".
    Как лучше: применять там, где он дает максимальную отдачу (сложная логика, высокая цена ошибки).

Мини-план внедрения в команде​

  1. Договориться о слоях: что считаем unit, integration, UI, E2E.
  2. Ввести обязательный быстрый прогон unit + integration в CI на каждый PR.
  3. Оставить компактный E2E smoke-набор по критическим сценариям.
  4. Для новых бизнес-фич фиксировать приемку в формате Given/When/Then (BDD-подход).
  5. На сложной доменной логике внедрять TDD точечно.

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

Реалистичный баланс слоев​

Для большинства продуктовых команд рабочий ориентир выглядит так: больше всего unit, затем integration/API, далее небольшой слой UI и компактный E2E smoke по критичным бизнес-путям. Это помогает держать быстрый feedback и при этом не терять сквозную проверку релиза.

Кейс "слишком много E2E, релиз стал медленным"​

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

Практичный пересмотр:

  • оставить в E2E только P0/P1 бизнес-пути;
  • перенести проверку логики в unit и integration;
  • дубли между слоями фиксировать на ревью тестового набора.

Такой рефакторинг обычно сокращает время обратной связи без потери качества на критичных сценариях.

Навигация по разделу "Тестирование"​

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").

Ещё 21 статей в разделе

Освоение главы0%