REST API.Правильная валидация сложного Json.

Всем привет!
На данный момент написана часть тестов для REST API с использованием Java, Junit и т.д.
Выдали ТЗ со второй частью, в которой ответ собирается из разных источников, в разных форматах(json, xml).
Нам нужно проверить json метода API с тем что собирается из разных источников.
Делал ли кто нибудь что-то подобное?
Есть ли примеры или может совет по выбору библиотеки или вообще другого подхода?
Главная проблема в том, что размер и содержания ответа метода зависит от типа пользователя, и может быть 10000 строк или 100.

Добрый день!
То есть ты хочешь сказать, что на запрос тебе прилетает респонс, в котором данные хранятся и в json и в xml одновременно? Это как вообще?
Можно пример?

По поводу библиотечки - мне очень нравится RestAssured - покрывает наверное все нужды API тестирования.
Пока писал, @kulasovvlad уже добавил линку, кстати

Но тут дело не в самой библиотеке.
Если всё же тебе необходимо парсить разные респонсы, которые могут быть в разных форматах (json и xml например), то тогда есть смысл использовать мапперы из json-a в java объект (например jackson или gson) и из xml в java объект соответственно (jaxb).
А после уже выполнять необходимые ассёрты

1 лайк

Mock - i в помощь … либо же валиднуть структуру при помощи JAckson Library… если нужно проверить отдельное поле то советую JsonPath библиотеку. Если и структуру и контент , формат данних итд то проблема Ваша заключаеться не в тому как ето все распарсить, а в тому где взять правильний expected result на такой большой response

1 лайк

посмотрите как гугловская пебличная АРІ сделана , например google maps - один и тот же реквест возвращает либо json, либо xml , в зависимости от параметра какой передаеться … я думаю ето имееться в виду

Нет конечно, мне прилетает json, а этот json собирается разрабами из 3-4 разных мест и форматов, и проверить нужно не совпадения по типам, и именно сожержимое всех объектов.

А, я понял.
Да. имеет смысл

Так и есть, это наша головная боль.

ну я когда то мокал, кое что генерировал разними способами, кое что из БД брал итд - потом JSON обьект на ходу по етим данним создавал и с ним сравнивал

есть парочка вопросов к вам :slight_smile:

у вас есть апи, на которое вы отправляете некий реквест, этот реквест может быть, к примеру из 5-ти параметров. Но после выполнения запроса в респонсе может быть очень много данных из разных сущностей? Зависит якобы все от юзера. Тоесть это большой список юзеров и у каждого свое количество параметров в json респонсе и происходит это из-за того, что в приложении пользователь жил своей какой-то жизнью? и после того, как один из этой сотни пользователей чето у ся изменит или по бизнес логике что-то изменит или сделает и у него уже количество и значения этих параметров может изменится, что-то на подобии такого?

Непонятно просто вот этот момент - “Нам нужно проверить json метода API с тем что собирается из разных источников.”

Или же этот реквест возвращает для разного пользователя разные набор параметров в респонсе. Тоесть, если в параметре при реквесте на апи отправляете айдишник пользователя, оно выводит json-респонс с 10-тью параметрами, а при указывании в реквесте айди другого пользователя - возвращает респонс уже с другими параметрами и там моожет количество параметров значительно больше? Типо все зависит от того какой пользователь и че делал в приложении…

Было бы здорово увидеть пример двух разных запросов и респонс к каждому из них, с разным количеством параметров.

По поводу библиотечки - тоже использую RestAssured. Для того, чтобы понимать, что возвращается мне после реквеста в респонсе при работе с юзером. Я сделал себе модельку User, у которой data mapping идет посредством jackson-databind

Модельку можно сгенерировать по json респонса - http://www.jsonschema2pojo.org/

ваще вы должны работать с обьектом, после каких-то манипуляций вы можете получить данные пользователя и замапить их в обьект User, а потом уже геттерами из этого обьекта получать нужные вам данные и сравнивать в тесте с тем, что лежит в базе данных

знать бы, что вы имели ввиду, под - “Нам нужно проверить json метода API с тем что собирается из разных источников.”

1 лайк

Если я правильно понял задание, то я бы решал примерно так:

  1. Необходимо получить респонз для ожидаемого типа пользователя (из БД или сервис), получить респонз для других ожидаемых параметров.
  2. Собрать все это в один объект Expected Result
  3. Собственно отправить запрос, полученный ответ десериализовать - это будет Actual Result
  4. Сравнить 2 объекта

В Groovy можно использовать Expando и не заморачиваться с описанием всевозможных комбинаций объектов. Потом собрать это все в один объект

def expectedObject = new Expando()
expectedObject.properties.putAll(N.properties)
//N - респонз для ожидаемого типа пользователя или другие параметры

И какой то компаратор типа

def compare = { actual, expected ->
    expected.properties.each {
        if (!actual.properties.containsKey(it.key) || actual.properties.get(it.key)!=it.value)
            println("Key $it not as actual")
    }
}

@Sergey_Pirogov больше не топит за Groovy :sunglasses:

1 лайк

Груви умер, Kotlin на арене

Спасибо всем большое за ответы!
Решили делать классы для каждой сущности и собирать и валидировать их отдельно!
По поводу ответа, это полная информация о пользователе сотового оператора, и если у него есть дочерние номера, архивные услуги, домашний интернет, долгая история со спец педложениями, то ответ растет в геометрической прогрессии.
Короче чтобы протестировать этот сервис нам придется писать практически его аналог.
Был приятно удивлен активностью на форуме, еще раз всем спасибо!

Ты это ))) Kotlin пока все еще не так гибок как грувя, особенно в вопросах работы с json’aми там всякими.

Не стоит этого делать - такие задачи решаются через наборы тестовых данных, которые должны полностью покрывать код агрегатора.