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

программирование java
, , ,
#1

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

#3

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

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

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

1 лайк
#4

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

1 лайк
#5

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

#6

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

#7

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

#8

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

#9

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

#10

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

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

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

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

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

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

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

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

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

1 лайк
#11
#12

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

  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 лайк
#13

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

#14

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

#15

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

#16

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