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

Unit, Integration, UI, E2E, TDD и BDD

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

Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.

Частая путаница: 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.

  1. Unit (Модульные тесты). Проверяют минимально возможную изолированную часть кода (юнит) — обычно одну функцию или класс. Все внешние зависимости (базы данных, сетевые запросы) заменяются "заглушками" (моками/стабами).
  2. Integration (Интеграционные тесты). Проверяют, как несколько модулей или систем работают вместе. Помогают найти ошибки в интерфейсах передачи данных и несовместимости форматов.
  3. UI (Тесты интерфейса). Фокусируются исключительно на графическом интерфейсе приложения. Могут проверять стили, адаптивность, корректное отображение шрифтов и работу элементов управления. Данные с сервера при этом часто подменяются mock-файлами.
  4. E2E (End-to-End или Сквозные тесты). Имитируют действия реального человека в браузере или приложении на «живом» окружении. Проходят через все слои системы: фронтенд, бэкенд, базы данных, сторонние сервисы оплаты и т.д.
  5. TDD (Test-Driven Development) — Разработка через тестирование - это концепция, когда сначала пишется тест, а затем код, который этот тест удовлетворяет.
  6. BDD (Behavior-Driven Development) — Разработка через поведение предполагает расширение TDD, где тесты описываются в виде понятных бизнес-сценариев на естественном языке (обычно на синтаксисе Gherkin).

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

Unit​

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

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

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

Integration​

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

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

Подробнее: Интеграционное тестирование, Тестирование и анализ API. На JVM — учебный HTTP-клиент с embedded JMeter: Практикум — API-тестер на Groovy.

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) — раздел "Методология и жизненный цикл ПО".

Теория шага Refactor — Методы рефакторинга; что такое unit (функция, класс) — Код — о разделе.

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;
  • дубли между слоями фиксировать на ревью тестового набора.

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

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

Содержание