Названия Unit, Service, UI и E2E описывают разные стороны проверки. Unit и Service обычно говорят о границе охвата, UI — о точке взаимодействия, E2E — о ширине бизнес-цепочки. Поэтому UI-тест не обязательно является полноценным E2E, а сквозная проверка может выполняться через API без браузера.
Для QA это практическое различие. Прежде чем обсуждать покрытие, полезно нарисовать границу: что запускается реально, какие зависимости заменены и какой результат наблюдаем. Тогда слово «интеграционный» перестаёт скрывать несколько разных видов испытаний.
Unit: небольшая ответственность
Unit-тест проверяет ограниченную единицу поведения в управляемых условиях. Это может быть функция, класс или небольшой связанный модуль. Обычно внешнюю сеть, часы и хранилище заменяют контролируемыми зависимостями, чтобы проверка объясняла конкретное правило.
Например, расчёт доставки получает вес, регион и тариф. На этом уровне удобно проверить нулевой вес, границы диапазона, округление и недопустимый регион. Но успех не доказывает, что HTTP-обработчик правильно передаёт регион из запроса или что интерфейс показывает рассчитанную цену.
Service: поведение на границе сервиса
Сервисная проверка обращается к публичной границе приложения или его части. Часто это HTTP API, очередь или RPC. Здесь важны валидация, права, коды ответа, сериализация и изменение состояния. Реальность базы и соседних сервисов определяется целью набора.
Укажите это явно: «API с настоящей тестовой базой и заглушенным платёжным провайдером». Такой тест хорошо проверяет сохранение заказа, но не подтверждает совместимость с настоящим провайдером. Для последней нужна отдельная контрактная или интеграционная проверка в согласованном контуре.
UI: пользовательский интерфейс
UI-проверка взаимодействует с представлением: браузером, компонентом или мобильным экраном. Она может проверять форму с подставленным API-ответом и вообще не запускать backend. Такой вариант полезен для состояния ошибки, загрузки, пустых данных и взаимодействия элементов.
Если ответ сервера полностью контролируется тестом, зелёный результат доказывает правильность обработки именно этого ответа. Он ничего не говорит о том, выдаёт ли backend такой формат в реальности. Поэтому договорённость о данных и отдельная проверка контракта остаются необходимыми.
E2E: целостная цепочка
End-to-end проверяет взаимодействие нескольких важных частей системы от входа до бизнес-результата. Например, создание заказа через UI, обработку сервисом и появление заказа в истории. При этом нужно заранее определить, где заканчивается цепочка: на принятии платежа, отправке события или фактической доставке уведомления.
Тест с подставленным платежом может оставаться полезной широкой проверкой вашего приложения, но это ограничение указывают в названии или документации. Абсолютная «реальность всего» не всегда достижима и не всегда нужна: важнее честно описать, какую связь проверяют.
Контрактные проверки между уровнями
Контрактный тест проверяет договорённость между потребителем и поставщиком: поля, типы, обязательность и допустимые варианты ответа. Он помогает находить несовместимость раньше полного сквозного прогона. Проверка схемы является одним из инструментов, но не подтверждает смысл всех значений.
Ответ с корректной JSON-структурой может содержать чужой заказ или неверную сумму. Поэтому контракт дополняют бизнес-проверками. С другой стороны, тест бизнес-расчёта не обнаружит переименование поля, которое сломает потребителя. Это разные обязанности, и смешивать их в одной метрике покрытия неудобно.
Практический пример: смена адреса
В учебном магазине заказ можно отправить только на разрешённый адрес. Возьмите пользователя Анну, её заказ в статусе draft и адрес в неподдерживаемой стране. По требованиям система должна отказать в сохранении, показать сообщение и сохранить предыдущий адрес заказа.
Unit-тест проверяет правило допустимой страны. Service-тест отправляет запрос изменения адреса и ожидает согласованный код ошибки, код причины в JSON и отсутствие изменения записи. UI-тест с контролируемым ответом проверяет, что сообщение видно и введённые поля не теряются.
Один E2E повторяет запрет через настоящий интерфейс и сервис. Затем разрешённый адрес проходит до сохранения. Если сквозной тест падает при зелёных узких проверках, QA сравнивает фактический запрос, ответ и отображение: возможна ошибка связывания полей или неверная обработка контракта.
Где готовить данные
Подготовка не должна незаметно менять предмет проверки. Если тестируете оформление заказа, пользователя можно создать через fixture или тестовое API. Если проверяете регистрацию, создавать пользователя заранее нельзя: это удалит из сценария нужную часть поведения.
Операции подготовки должны возвращать конкретные идентификаторы и обеспечивать независимость. Общий заказ «для всех тестов» создаёт зависимость от порядка. Отдельные данные и управляемая очистка позволяют запускать один сценарий локально и параллельно с другими без изменения результата.
Как выбирать уровень для дефекта
После обнаружения ошибки спросите, на каком минимальном уровне воспроизводится её причина. Неверное округление требует узкой регрессии. Потерянный заголовок авторизации требует проверки границы. Недоступная после открытия клавиатуры кнопка требует UI на подходящем устройстве.
Иногда нужны два теста: узкий для подробной причины и широкий для соединения частей. Но не обязательно переносить все варианты дефекта в браузер. Критерий — разные риски и разная диагностическая ценность, а не желание продублировать количество.
Типичные ошибки и выводы
Нельзя считать каждый HTTP-тест интеграционным с реальными зависимостями или каждый браузерный тест сквозным. Также опасно оценивать качество только количеством кейсов: сто проверок одной формулы не компенсируют отсутствие контроля доступа к заказу.
Зафиксируйте в проекте словарь уровней и несколько примеров. Для каждого набора опишите границы, заменённые зависимости, данные и ожидаемый сигнал. Такая прозрачность помогает QA и разработчикам распределять работу и понимать, что именно означает зелёный запуск.
Обсуждение границ полезно повторять после изменения архитектуры: прежнее название набора может больше не соответствовать реально запускаемым компонентам.