Ожидание формулируют до запроса
Представим учебный сервис с карточками предметов. Запрос одной карточки должен возвращать данные именно выбранного предмета, а не любого существующего. Значит, кроме статуса важны идентификатор, обязательные поля и согласованность значений. Ожидание нельзя полностью вычислять из того же ответа, который проверяется: такая проверка легко подтверждает сама себя. Нужна независимая опора, например заранее подготовленные тестовые данные и согласованный контракт. При этом не следует фиксировать случайные детали, которые договорённость не обещает. Излишне жёсткий тест будет падать после допустимых изменений оформления, не обнаруживая реального нарушения.
Инструменты выполняют разные задачи
REST Assured помогает описывать HTTP-запросы и проверки ответов в Java. TestNG организует запуск тестовых методов, подготовку окружения и передачу наборов данных. Эти роли дополняют друг друга, но сами инструменты не определяют правильное поведение сервиса. Набор вариантов можно передавать в один проверяющий метод, сохраняя понятные различия между случаями. В отчёте об ошибке важно видеть ожидаемое и фактическое значение, а также выбранный сценарий. Секреты и личные сведения не должны попадать в журналы вместе с полным запросом. Удобство диагностики нужно сочетать с минимизацией сохраняемых данных.
Независимость важнее случайного порядка
Тест, который работает только после другого теста, может скрывать зависимость от оставшегося состояния. Лучше явно готовить необходимые данные и понимать, кто их удаляет. Параллельный запуск особенно быстро выявляет конфликты, если несколько проверок меняют один объект. Негативный сценарий проверяет согласованную реакцию на недопустимый ввод, а не просто любое падение. Отсутствие сети и корректный отказ сервиса означают разные события. Повторный запуск иногда помогает диагностике, но не должен бесконечно скрывать нестабильность. После сбоя полезно выяснить, нарушен контракт, ошибочны данные теста или недоступно окружение.
Попробуйте на практике
Составьте на бумаге план проверки вымышленного API каталога. Никакие запросы к реальным сайтам выполнять не нужно.
- Опишите одну карточку с искусственным идентификатором, названием и количеством. Укажите, какие поля обязательны и откуда известно ожидаемое значение.
- Сформулируйте успешный сценарий: исходное состояние, запрос и три отдельные проверки ответа. Сделайте хотя бы одну проверку содержательной, а не только технической.
- Добавьте случай отсутствующей карточки и случай недопустимого ввода. Для каждого запишите конкретное ожидаемое поведение, не придумывая его по фактическому сбою.
- Распределите обязанности между подготовкой данных, отправкой запроса и утверждениями. Проверьте, смогут ли два экземпляра сценария выполняться без конфликта.
Как проверить результат. Каждый сценарий имеет независимое ожидание и понятную причину возможного падения. Успешный статус не подменяет проверку содержания, а тестовые данные не зависят от случайного порядка.
Частые вопросы
Нужно проверять каждое поле каждого ответа?
Проверки выбирают по контракту и рискам. Механическое сравнение всего ответа может закрепить случайные детали и сделать тест хрупким.
Если повторный запуск зелёный, проблему можно закрыть?
Не автоматически. Нужно понять причину нестабильности. Повтор может скрыть конфликт данных, зависимость от времени или реальный сбой.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.