Skip to main content

REST-Assured 3.0

I started using REST-Assured framework around version 1.5 and since then it’s my first-choice REST client for test automation projects. Back then it was very straight forward, but still way better than it’s available, verbose equivalents. It’s major pros are ease of use – you basically add one static import and you’re ready to go, and BDD convention, which improves readability a lot. But when you dive deeper into REST-Assured framework, you’ll find many handy features, like object serialization, built-in assertions, response manipulation, etc. I already write two post about REST-Assured (framework overview, and more advanced), which become two most popular articles on my blog. Since then the framework gained a lot of popularity and it’s still being developed.

We have version 3.x now, with some great announcements. If you don’t want to study release notes (which I highly recommend!), take a look at this post, with overview of the major changes and new features.

Dependencies 

First of all, 3.0.0 version introduces new group-id. If you’re a Maven user, you need to change your dependency as follows:

<dependency> 
    <groupId>io.rest-assured</groupId> 
    <artifactId>rest-assured</artifactId> 
    <version>${restassured.version}</version> 
</dependency>

…and If you’re on the light side of the force – dependency for Gradle:

testCompile group: 'io.rest-assured', name: 'rest-assured', version: restassured.version

Of course, If you want to follow this convention you need to define restassured.version as a variable.

JsonPath object serialization 

In most projects, domain model is a vast part of the code base. In automated acceptance tests usually we need rather small portion of model or just simple domain-transfer objects. REST-Assured makes creating models easier by partial response serialization (example below comes from official documentation). 

Let’s assume you have a following response:


But you don’t want to handle whole store object for your tests, you just want to have a list of book objects. With use of JsonPath, you serialize extracted list:

List books = JsonPath.from(json).getList("store.book", Book.class);

Validating response time 

Latency is a huge factor in the world of distributed systems and microservices. Since in REST architecture we use HTTP calls, response time is yet another value to measure. In REST-Assured 3.x (it was originally introduced in version 2.8) you can not only measure HTTP response times:

long responseTime = get("https://testdetective.com").time()

…but also make assertions based on response time:

when() 
    .get("https://testdetective.com")
.then() 
    .time(lessThan(5000L));

Injecting request method 

Announced with 3.0 release, REST-Assured offers now a possibility to inject HTTP method as a request() method parameter. This feature adds tons of flexibility to your test development: you can use custom methods, conditional-pass request methods or just parametrize test cases. Below you can check example of a data-driven test case parametrized with HTTP method and expected response (test runner is spock):


With use of request() method and some spock magic, We have several test-cases (see @Unroll annotation) with no code-repetition:


Continue reading 

If you want to continue reading and expand your knowledge in area of REST and microservices, I recommend you these books:

  • Building Microservices – one of the most important books for me, everything you want to know about microservices is here
  • Java For Testers: Learn Java fundamentals fast – test automation does not require complex programming knowledge. Learn fundamentals of Java for test automation. From tester to testers!
  • RESTful Web APIs – another great book about REST architecture. Lots of practical knowledge about designing and consuming RESTful APIs


Summary 

For those who’re looking for REST client for automated tests, give a try to REST-Assured. With 3.0 release and it’s new features it’s very flexible yet powerful tool.


Etykiety:

Popular posts from this blog

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous  If a
Read more

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation. If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon. Instalation  If you are an maven user, add following dependency: <dependency>       < groupId > com.anotherchrisberry < /groupId >       < artifactId > spock-retry < /artifactId >       < version > 0.6.2 < /version >       < type > pom < /type >   </dependency> For gradle users:
Read more

Performance Testing – Vegeta Attack!

Performance testing is crucial field of modern software development. Taking into account that in today’s world majority of app’s communication is web-based, it turns out to be even more important. However, it still enjoys less interest than automated functional testing, and publications on load testing subject usually focus on mature and complex tools like JMeter or Gatling. In this post I’d like to introduce command line usage of a super simple and lightweight tool for performance testing of HTTP services, which is Vegeta. Who is Vegeta  Besides Dragon Ball’s character, Vegeta is a simple load testing tool written in GO, that can be used both from command line and as an external library in your project. In order to use Vegeta, download executables from here . It is recommended to set environment variable for ease of use.  For Mac users, you can download vegeta directly from Homebrew repositories: $ brew update && brew install vegeta Vegeta’s Arsenal  Usage
Read more