Возможны собственные тестовые DTO, модели разработчиков и проверки отдельных JSON-полей; выбор зависит от независимости теста и того, какую часть контракта он проверяет.
Для API использовали DTO-классы разработчиков или сами описывали, или вообще строками проверяли в REST Assured?
Возможны собственные тестовые DTO, модели разработчиков и проверки отдельных JSON-полей; выбор зависит от независимости теста и того, какую часть контракта он проверяет.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Возможны собственные тестовые DTO, модели разработчиков и проверки отдельных JSON-полей; выбор зависит от независимости теста и того, какую часть контракта он проверяет.
Общие DTO удобны, но одинаковая ошибка модели у клиента и теста может скрыть несовместимость внешнего API. Собственные модели дают независимость ценой сопровождения. Для небольших проверок REST Assured позволяет проверять отдельные поля и структуры без десериализации всего ответа. Сравнение сырой JSON-строки обычно хрупко из-за порядка полей и форматирования. Важно проверять обязательность, типы и смысл значений, а не только возможность распарсить ответ тем же кодом, что использует приложение.