REST-assured: полезные советы

[@vikarti]

Было бы хорош еще и статью по основам

REST-assured, одной из самых распространенных Java-библиотек для автоматизации тестирования REST-API.

[@savkk]

Порог вхождения в автоматизацию тестирования с использованием библиотеки REST-assured невероятно низкий. Именно поэтому эта библиотека такая распространенная, но это же и её бич — многие заканчивают изучение на статьях «по основам». В интернете много таких статей, но я бы порекомендовал почитать официальную документацию, которая к слову очень хорошая.

[@Sad_Bro]

Спасибо, но очень кратко. Есть пример образцового проекта с использованием restAssured?

[@savkk]

К сожалению, пример образцового проекта показать не смогу. Да и нет, наверное, его. Видел много различных проектов, с различной архитектурой, и у каждого были свои плюсы и минусы. Например, можно практически всё описать зеркально с тестируемого приложения. Вынести контроллеры в отдельные классы, там собрать вызовы методов этих контроллеров, в тестах же оставить только проверки. Если же в тестируемом приложении используется flow, то можно попробовать пойти от описания шагов этого flow. А может быть вообще стоит всё описать в тестовых методах и не париться. :)

[@Sad_Bro]

Да согласен, каждый делает по своему)
Еще чем нравится REST Assured это очень простая реализация проверки по json schema. К сожалению на рабочем проекте используется Retrofit, и там валидацию по схеме ввернуть так легко не вышло.

[@vakula_yo]

Про проверки. Если хочется проверить statusCode, но и что-то из body, все равно же не уложиться в конструкцию given-when-then?

«then().statusCode(200);»
Все равно придется заводить какие-то переменные и использовать assert?

[@savkk]

Можно, нужно продолжать цепочку вызовов, например так:
given().cookie(«key», «value»)
.when().get(«someUrl»)
.then().statusCode(200).body(matchesJsonSchemaInClasspath(«schema.json»)).cookie(«newCookie»);
В данном случае будет 3 проверки:
1. Статус код соответствует 200;
2. Тело ответа соответствует Json Schema;
3. В ответ пришел новый куки с ключом «newCookie».
Единственный минус, что это не SoftAssert и если свалится на первой проверке, остальные не будут проверяться.
Но это очень редко требуется.
Для лучшей читабельности можно использовать вызов союза and():
...then().statusCode(200)
.and()
.body(matchesJsonSchemaInClasspath(«schema.json»))
.and()
.cookie(«newCookie»);
Терминальными методами являются только методы, вызываемые после метода extract():
...then().statusCode(200).extract().body().asString();

[@iEfimoff]

А как вы проверяете правильную сортировку данных?

[@savkk]

Правильно ли я понимаю, что данный вопрос не относится к REST-assured?
Сортировку лучше всего проверять зная то, что сортируется и как оно должно выглядеть после сортировки. Лучше всего это делать на уровне Unit-тестов.
Писать свою сортировку для проверки другой сортировки (если вы на это намекаете), мне кажется плохой вариант, но возможно, кто-то делает именно так.
Я бы заполнил нужную коллекцию известными мне данными и после сортировки проверил, что они имеют ожидаемый порядок.

[@VitP]

Начал недавно работать с этой библиотекой и вскоре столкнулся с таким вопросом: стоит ли десерилизовать ответ в класс или можно обойтись матчерами Hamcrest прямо в методе body()?
Можете рассказать на этот счёт?

[@savkk]

Если ваша задача только осуществить проверку полученного ответа, то необходимости в десериализации точно нет. REST-assured и Hamcrest позволяют осуществить любую проверку. Если же вам необходимо в дальнейшем каким-то образом работать с сущностью, полученной в ответе, то можно воспользоваться десериализацией.

[@VitP]

Пока справляюсь средствами RestAssured и Hamcrest. Но думаю, может, я чего-то упускаю, не делая десирелиазацию.

А каким образом с сущностью можно работать далее, выполнив десериализацию? Что обычно делают?

[@savkk]

Десериализация может понадобиться, например, для осуществления долгосрочного хранения или преобразования сущности в другой формат.

[@Ivan_Sidorenko]

Отличная статья. Кратко и по делу.