Как проверять ответы JSON и XML с помощью путей и правил

Почему полное сравнение ответа хрупкое

Два семантически одинаковых JSON-документа могут отличаться порядком полей и форматированием. Ответ также часто содержит динамические значения: идентификатор, дату создания, время обработки. Если сравнить весь текст с эталоном, корректное изменение такого значения даст ложное падение.

В XML добавляются объявления пространств имён, атрибуты, повторяющиеся узлы и различия в пробелах. Строковое равенство может сломаться из-за сериализации, хотя прикладные данные не изменились. Поэтому устойчивый подход обращается к конкретному пути и применяет к найденному значению отдельное правило.

Четыре вопроса к каждому значимому полю

1. Должно ли поле существовать? Обязательное значение и опциональное значение требуют разных правил. Не объявляйте поле обязательным только потому, что увидели его в одном примере.
2. Какой у него тип? Число, строка, логическое значение, объект, массив и XML-элемент несут разный контракт. Строка "42" и число 42 могут выглядеть похоже, но обрабатываются по-разному.
3. Какое значение допустимо? Для статуса может требоваться точное значение, для идентификатора — непустое значение, для количества — диапазон, а для текста ошибки — стабильный код вместо полного сообщения.
4. С чем оно связано? Идентификатор в ответе создания должен совпадать с идентификатором объекта в следующем запросе. Количество элементов может быть связано с массивом. Именно такие отношения часто отражают бизнес-смысл.

Пошаговая валидация JSON

1. Подтвердите транспортный уровень. До разбора тела проверьте ожидаемый HTTP-статус и Content-Type. HTML-страница ошибки вместо JSON должна давать ясное падение формата, а не загадочную ошибку пути.
2. Выберите устойчивую точку входа. Начните с корня и обязательных верхнеуровневых полей. Путь должен описывать структуру контракта, а не случайное расположение элемента в конкретном примере.
3. Разделите правила. Для ключевого поля задайте наличие, затем при необходимости тип и значение. Когда правило падает, такое разделение показывает: поле отсутствует, имеет неверный тип или содержит неверные данные.
4. Обработайте массив осознанно. Индекс первого элемента подходит только тогда, когда порядок гарантирован контрактом. Если порядок не определён, лучше искать элемент по устойчивому признаку или проверять свойства коллекции, которые действительно обязательны.
5. Не фиксируйте динамические значения. Для ID проверяйте наличие и пригодность к дальнейшему использованию. Для времени — формат или логическую границу, если она задана требованиями. Случайный токен нельзя сравнивать с прошлым ответом.
6. Проверьте негативный ответ отдельно. У ошибки может быть другая структура. Ожидайте документированный статус, обязательный код и стабильные поля. Человеко-читаемый текст способен меняться и локализоваться, поэтому он редко является лучшим единственным признаком.

Пошаговая валидация XML

1. Убедитесь, что получен XML. Проверьте статус и заявленный тип содержимого, затем возможность разобрать документ. Ответ прокси в HTML нельзя анализировать как штатный XML.
2. Определите значимые элементы и атрибуты. Контракт может хранить данные и в тексте узла, и в атрибуте. Проверяйте то представление, которое зафиксировано схемой или документацией.
3. Учитывайте пространство имён. Одинаковые локальные имена элементов могут принадлежать разным пространствам. Путь должен однозначно обращаться к нужному узлу, особенно в SOAP-сообщениях.
4. Разберите повторяющиеся элементы. Не предполагайте, что нужный узел всегда первый, если порядок не обещан. Для коллекции сформулируйте правило количества, наличия нужного элемента или свойств каждого обязательного элемента.
5. Отделите SOAP-оболочку от полезной нагрузки. Для SOAP/WSDL сначала подтвердите корректный Envelope и Body, затем проверяйте бизнес-данные. SOAP Fault является структурированным ответом об ошибке и требует собственного набора ожиданий.
6. Сравнивайте значения после разбора. Отступы, переносы строк и порядок независимых атрибутов не должны становиться причиной падения, если не являются частью явного требования.

Как использовать извлечённые значения в сценарии

Путь нужен не только для утверждения. Значение из ответа можно сохранить в переменную и подставить в следующий запрос. Типичная последовательность выглядит так: создать ресурс, извлечь его ID, запросить ресурс по этому ID и сравнить ключевые поля с исходными данными. Это подтверждает связность операций и убирает ручное копирование.

Переменная должна появляться только после успешной проверки источника. Если поле ID отсутствует, следующий шаг с пустым адресом создаст вторичную ошибку и затруднит диагностику. Названия переменных должны отражать смысл и область: createdOrderId понятнее, чем value1.

Структура, значение и бизнес-правило

Структурная проверка

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

Проверка значения

Подтверждает точное или допустимое значение: состояние равно created, количество не отрицательно, код ошибки соответствует сценарию. Границы должны исходить из требований, а не из случайного наблюдения.

Проверка связи

Сопоставляет части ответа или разные шаги. Например, ID в URL второго запроса равен ID в его теле, а итоговый статус относится к объекту, созданному в начале сценария. Такие правила часто находят ошибки, незаметные при проверке отдельных полей.

Распространённые ошибки

• Снимок всего ответа как эталон. Он захватывает даты, идентификаторы, порядок и форматирование, создавая ложные падения.
• Проверка только наличия. Поле может существовать с неверным типом, пустым или недопустимым значением.
• Жёсткий индекс массива. Если порядок элементов не гарантирован, второй корректный ответ может переставить их.
• Игнорирование null и отсутствия. Это разные состояния контракта. Определите, что именно разрешено.
• Один набор правил для успеха и ошибки. Ответы 2xx и 4xx/5xx обычно имеют разные структуры и смысл.
• Проверка текста сообщения вместо кода. Формулировка может измениться без изменения типа ошибки.
• XML-путь без пространства имён. Он может находить не тот элемент или перестать работать на корректном документе.

Где здесь подходит Checkcraft

Checkcraft позволяет визуально отправлять HTTP-запросы и задавать проверки статуса, заголовков, тела и времени ответа. Для JSON и XML доступны пути и правила; значения можно сохранять в переменные и использовать в многошаговых сценариях. Запросы можно импортировать из cURL, OpenAPI/Swagger и Postman. Для XML-ориентированных систем предусмотрена работа с SOAP/WSDL, а для других задач — WebSocket, gRPC и Mock Server.

Приложение работает на Windows, данные проекта по умолчанию сохраняются в локальном workspace. Сейчас идёт закрытая бета по заявкам: публичного скачивания и публичной оплаты нет. Checkcraft помогает выразить проверки в интерфейсе, но выбор правильного пути и правила по-прежнему должен опираться на документацию и реальный контракт конкретного API.