Комментарии 14
Было бы хорош еще и статью по основам
REST-assured, одной из самых распространенных Java-библиотек для автоматизации тестирования REST-API.
Порог вхождения в автоматизацию тестирования с использованием библиотеки REST-assured невероятно низкий. Именно поэтому эта библиотека такая распространенная, но это же и её бич — многие заканчивают изучение на статьях «по основам». В интернете много таких статей, но я бы порекомендовал почитать официальную документацию, которая к слову очень хорошая.
Спасибо, но очень кратко. Есть пример образцового проекта с использованием restAssured?
К сожалению, пример образцового проекта показать не смогу. Да и нет, наверное, его. Видел много различных проектов, с различной архитектурой, и у каждого были свои плюсы и минусы. Например, можно практически всё описать зеркально с тестируемого приложения. Вынести контроллеры в отдельные классы, там собрать вызовы методов этих контроллеров, в тестах же оставить только проверки. Если же в тестируемом приложении используется flow, то можно попробовать пойти от описания шагов этого flow. А может быть вообще стоит всё описать в тестовых методах и не париться. :)
Про проверки. Если хочется проверить statusCode, но и что-то из body, все равно же не уложиться в конструкцию given-when-then?
«then().statusCode(200);»
Все равно придется заводить какие-то переменные и использовать assert?
«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();
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-тестов.
Писать свою сортировку для проверки другой сортировки (если вы на это намекаете), мне кажется плохой вариант, но возможно, кто-то делает именно так.
Я бы заполнил нужную коллекцию известными мне данными и после сортировки проверил, что они имеют ожидаемый порядок.
Сортировку лучше всего проверять зная то, что сортируется и как оно должно выглядеть после сортировки. Лучше всего это делать на уровне Unit-тестов.
Писать свою сортировку для проверки другой сортировки (если вы на это намекаете), мне кажется плохой вариант, но возможно, кто-то делает именно так.
Я бы заполнил нужную коллекцию известными мне данными и после сортировки проверил, что они имеют ожидаемый порядок.
Начал недавно работать с этой библиотекой и вскоре столкнулся с таким вопросом: стоит ли десерилизовать ответ в класс или можно обойтись матчерами Hamcrest прямо в методе body()?
Можете рассказать на этот счёт?
Если ваша задача только осуществить проверку полученного ответа, то необходимости в десериализации точно нет. REST-assured и Hamcrest позволяют осуществить любую проверку. Если же вам необходимо в дальнейшем каким-то образом работать с сущностью, полученной в ответе, то можно воспользоваться десериализацией.
Отличная статья. Кратко и по делу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
REST-assured: полезные советы