Как стать автором
Обновить

Комментарии 14

Было бы хорош еще и статью по основам
REST-assured, одной из самых распространенных Java-библиотек для автоматизации тестирования REST-API.
Порог вхождения в автоматизацию тестирования с использованием библиотеки REST-assured невероятно низкий. Именно поэтому эта библиотека такая распространенная, но это же и её бич — многие заканчивают изучение на статьях «по основам». В интернете много таких статей, но я бы порекомендовал почитать официальную документацию, которая к слову очень хорошая.
Спасибо, но очень кратко. Есть пример образцового проекта с использованием restAssured?
К сожалению, пример образцового проекта показать не смогу. Да и нет, наверное, его. Видел много различных проектов, с различной архитектурой, и у каждого были свои плюсы и минусы. Например, можно практически всё описать зеркально с тестируемого приложения. Вынести контроллеры в отдельные классы, там собрать вызовы методов этих контроллеров, в тестах же оставить только проверки. Если же в тестируемом приложении используется flow, то можно попробовать пойти от описания шагов этого flow. А может быть вообще стоит всё описать в тестовых методах и не париться. :)
Да согласен, каждый делает по своему)
Еще чем нравится REST Assured это очень простая реализация проверки по json schema. К сожалению на рабочем проекте используется Retrofit, и там валидацию по схеме ввернуть так легко не вышло.
Про проверки. Если хочется проверить statusCode, но и что-то из body, все равно же не уложиться в конструкцию given-when-then?

«then().statusCode(200);»
Все равно придется заводить какие-то переменные и использовать assert?
Можно, нужно продолжать цепочку вызовов, например так:
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();
А как вы проверяете правильную сортировку данных?
Правильно ли я понимаю, что данный вопрос не относится к REST-assured?
Сортировку лучше всего проверять зная то, что сортируется и как оно должно выглядеть после сортировки. Лучше всего это делать на уровне Unit-тестов.
Писать свою сортировку для проверки другой сортировки (если вы на это намекаете), мне кажется плохой вариант, но возможно, кто-то делает именно так.
Я бы заполнил нужную коллекцию известными мне данными и после сортировки проверил, что они имеют ожидаемый порядок.

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

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

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


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

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