Пользователь оформил заказ, сайт показал подтверждение, а сотрудник не видит его в системе учёта. Где искать ошибку: в форме, сервере, базе или обмене с внешним сервисом? Проверка каждого компонента по отдельности на этот вопрос не отвечает.
Мы в Гуси-Лебеди предлагаем начинать интеграционное тестирование с конкретного результата: какие данные должны пройти между компонентами и что должно измениться у получателя. Разберём это на условном заказе, включая задержку ответа, повторную отправку и восстановление после сбоя.
Что проверяет интеграционное тестирование и где провести границы
Интеграционное тестирование проверяет совместную работу двух или нескольких компонентов. В центре внимания находятся их интерфейсы, передача данных и результат взаимодействия. Например, сервер не просто отвечает на запрос: он сохраняет заказ в базе с согласованными полями. Такое понимание уровня проверки используется и в документации Microsoft об интеграционных тестах.
Ошибка может возникнуть там, где обе стороны по отдельности выглядят исправными. Один компонент отправляет сумму в копейках, другой понимает её как рубли. Поле с идентификатором переименовано, а получатель продолжает читать прежнее название. Сервер сохранил объект, но ответ потерялся, и клиент повторил создание. Это условные примеры возможных несоответствий, а не описание ошибок в проектах Гуси-Лебеди.
Отличия от модульного, системного и сквозного тестирования
Модульный тест изолированно проверяет небольшую часть программы: например, расчёт стоимости корзины. Интеграционный проверяет, что рассчитанные данные правильно передаются и сохраняются при взаимодействии частей. Системное тестирование оценивает систему в целом по её требованиям. Сквозной тест, или E2E, проходит выбранный пользовательский путь от начала до конца.
Названия в командах могут различаться, поэтому лучше перечислить реальные участники теста. «Проверка API» тоже не определяет уровень автоматически. Запрос к серверу с настоящей базой проверяет одну границу; ответ полностью подменённого сервера подтверждает другую, более узкую часть поведения. Тест интерфейса с заглушкой внешнего сервиса не подтверждает фактическую работу этого сервиса.
Представим интернет-магазин: браузер передаёт заказ серверу, сервер записывает его в базу, затем отправляет во внешнюю систему учёта. Можно проверить сервер с базой отдельно, после этого добавить обмен с системой учёта и затем пройти путь через интерфейс. Для каждого шага понадобится своё ожидаемое состояние. Описание самой передачи запросов рассматриваем отдельно в статье о ресурсах, методах и ответах REST API.
Подходы: все компоненты сразу или постепенное подключение
При подходе Big Bang, или «большой взрыв», готовые компоненты объединяют сразу. Это позволяет проверить собранную связку, но при сбое приходится разбирать больше участников одновременно. Инкрементальный подход добавляет компоненты постепенно: легче связать новую ошибку с последним изменением, зато недостающие зависимости иногда нужно моделировать.
Восходящее тестирование движется от нижних уровней архитектуры к верхним, нисходящее в обратном направлении. Гибридный подход сочетает эти направления. Выбирать стоит по готовности компонентов и рискам. Для условного магазина полезно сначала подтвердить запись заказа в базу, а уже затем разбирать внешний обмен: так одна проверка не скрывает сразу несколько неизвестных.
Среда и тестовые данные: что должно быть настоящим
До запуска запишите версии приложения, схему базы, конфигурацию подключения и начальные данные. Если сегодня тест использует новую схему, а завтра старую, одинаковое название сценария не делает результаты сопоставимыми. Среда должна быть воспроизводимой в той части, которую вы проверяете.
В нашем условном магазине для проверки сервера с базой нужны настоящий серверный код и выбранная СУБД. Простая коллекция в памяти не воспроизводит все особенности настоящей базы: ограничения, запросы и поведение транзакций могут отличаться. При этом тестовую базу следует отделить от рабочей. Укажите, какие различия среды существенны для результата и какие зависимости заменены.
Для контейнеризованных зависимостей можно использовать Testcontainers. Библиотеки запускают реальные сервисы в контейнерах для тестов; это описано в официальной документации Docker. Контейнер сам по себе не делает окружение идентичным рабочему: версии, настройки и набор данных по-прежнему нужно выбирать осознанно.
Заглушка полезна, если понятно, что она не проверяет
Заглушка имитирует вызываемый компонент. Например, тестовая система учёта может возвращать успешное принятие заказа, отказ или задержанный ответ. Драйвер действует с другой стороны: инициирует вызов проверяемого компонента, когда настоящий инициатор ещё не подключён.
Такая замена позволяет воспроизводить нужные условия. Но зелёный тест с заглушкой не доказывает, что реальная система учёта примет тот же запрос. Её контракт, доступность и особенности обработки необходимо проверять отдельно в разрешённой среде. Контрактное тестирование помогает сопоставить ожидания отправителя и получателя: в документации Pact этот подход описан для HTTP-взаимодействий и сообщений. Оно не заменяет все проверки реального обмена и бизнес-процесса.
Подготовьте данные, которые можно узнать после запуска: отдельный тестовый заказ, товар с известной ценой и пользователя с заданными правами. Не используйте запись, которая уже случайно существует в базе. Для параллельных тестов предусмотрите независимые объекты, чтобы один запуск не удалял данные другого.
Отдельно проверьте маршруты внешних действий. Тестовая отправка не должна неожиданно создавать рабочий заказ, списывать деньги или рассылать письма клиентам. Для таких сценариев нужны согласованные тестовые подключения и получатели. В доказательствах оставляйте достаточно данных для диагностики, скрывая пароли, токены и реальные персональные сведения.
Пример тест-кейсов: заказ, отказ и потерянный ответ
Ниже условный сценарий, для которого заранее согласовано правило: заказ сохраняется у магазина, получает статус обмена и передаётся во внешнюю систему. Успех передачи подтверждается отдельно. Если ваш продукт устроен иначе, ожидаемые состояния будут другими. Таблица показывает способ составления проверки, а не готовую спецификацию для любого сайта.
| Условие | Действие | Что проверить кроме ответа |
|---|---|---|
| Корректные данные | Создать тестовый заказ | Заказ сохранён с верной суммой; внешняя система приняла согласованные данные |
| Нет обязательного поля | Передать неполный запрос | Отказ соответствует контракту; некорректный заказ не появился у получателя |
| Недостаточно прав | Запустить операцию от ограниченного пользователя | Нет запрещённого изменения данных, даже если интерфейс скрывает кнопку |
| Внешний сервис недоступен | Смоделировать отказ соединения | Статус обмена отражает проблему; заказ не назван успешно переданным |
| Ответ потерялся после принятия | Повторить запрос по согласованному правилу | Проверить фактическое число заказов и соответствие идентификаторов с обеих сторон |
| Сервис восстановился | Повторно обработать отложенный обмен | Объект дошёл до получателя; статус обновился; повтор не создал лишнюю операцию |
Для каждого случая нужны предусловия, входные данные, действие и ожидаемый результат. Формулировка «заказ работает» слишком расплывчата. «После отправки объект с тестовым идентификатором появился у получателя с согласованной суммой» позволяет проверить конкретный факт. Если обмен асинхронный, отдельно определите допустимое время ожидания по требованиям проекта.
Код ответа не заменяет проверку состояния
Успешный HTTP-ответ может означать принятие задачи, а не завершение всего процесса. Проверьте тело ответа, идентификатор, сохранённые данные и доступное подтверждение получателя. У этих наблюдений разное значение: запись об отправке в журнале показывает попытку, подтверждение принятия показывает следующий этап.
Для проверки ответа API можно использовать Postman: его официальные примеры проверок охватывают статус, заголовки и тело ответа. Однако нужное бизнес-состояние всё равно следует описать отдельно. Программа не угадает, какая сумма и какой статус верны для вашего заказа.
Повторная отправка: операция могла выполниться до тайм-аута
Самый неприятный вариант для нашего примера: система учёта создала заказ, но магазин не получил ответ. Тайм-аут у отправителя не доказывает, что получатель ничего не сделал. Поэтому обычный повтор «на всякий случай» способен создать второй объект, если защита от повторов не предусмотрена.
Когда контракт предусматривает идемпотентность, повтор той же операции не должен создавать дополнительный эффект. При использовании ключа операции проверьте повтор с тем же ключом, изменение содержимого запроса и условия, при которых ключ перестаёт действовать. Конкретные правила берутся из контракта сервиса. Риск повторов и способ различать операции разбирает Amazon Builders’ Library. Нельзя предполагать идемпотентность у любого API.
Не ограничивайтесь двойным нажатием кнопки. Повтор может прийти от фонового обработчика или после восстановления соединения. Для выбранных сценариев проверьте состояния у отправителя и получателя, а не только исчезновение сообщения об ошибке на экране.
Как разобраться в сбое и принять результат проверки
Если тест упал, сначала установите, что именно не совпало с ожиданием. Отказ запуска базы, неверная конфигурация и дефект приложения требуют разных действий. Не называйте каждый сбой стенда ошибкой продукта, но и не превращайте его в успешную проверку. Пока нужные компоненты не участвовали в сценарии, соответствующая связь остаётся непроверенной.
Для нашего заказа полезно сопоставить идентификатор запроса, объект в базе, событие отправки и ответ внешней системы. Если настроена трассировка, она помогает связать операции между сервисами; если нет, нужны доступные журналы и другие наблюдаемые данные. Отсутствие строки в одном журнале ещё не подтверждает отсутствие операции: сначала проверьте полноту этого источника.
Что записать в отчёт о дефекте
- Версию сборки, среду и состав настоящих компонентов и заменителей.
- Начальные данные, шаги и безопасные идентификаторы для воспроизведения.
- Ожидаемое состояние по требованию и фактически полученный результат.
- Подтверждения с обеих сторон обмена, если они доступны.
- Ограничения проверки: недоступный этап, отсутствующий журнал, неподтверждённое внешнее действие.
Хороший отчёт позволяет повторить ошибку. «Иногда не доходит заказ» оставляет слишком много неизвестных. Описание, какие данные отправлены, какой ответ получен и где отсутствует ожидаемый объект, сокращает область поиска. При разработке серверной части и интеграций эти правила полезно согласовать вместе с контрактами обмена.
После исправления повторите исходный случай и связанные сценарии: успешную передачу, отказ и повторную обработку. Если исправление изменило формат поля или правило статусов, прежний зелёный отчёт уже не подтверждает новую версию. При автоматизации тесты можно включить в конвейер выпуска, сохраняя результаты конкретных запусков. Организацию такого процесса рассматриваем в статье о проверках и выпуске изменений через CI/CD.
Количество пройденных тестов и покрытие строк кода не описывают все риски обмена. Для приёмки важнее перечень проверенных связей, результаты критичных сценариев, состояние замечаний и явные ограничения. Гуси-Лебеди рекомендует принимать интеграцию по воспроизводимым результатам: какие данные дошли, где они сохранились и что произошло при предусмотренном отказе. Так у команды есть основание для решения о выпуске, а не обещание отсутствия любых будущих ошибок.