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...
Read more

REST API mocking with Wiremock

Probably every developer or tester have used mocks at least once in their daily professional work. Functionality mocking is an excellent way to improve development process of integrated systems production, or testing heavy dependent application functionalities. With the growth of popularity of REST webservices, API mocking is becoming hot topic. In this article I would like to introduce a simple getting-started tutorial of setting basic standalone REST API mock server with Wiremock on your local machine. Wiremock is a simple library written in Java for mocking web services. Installation  To run standalone wiremock server, download jar from here and run: $ java -jar wiremock-1.55-standalone.jar you should see: This means that wiremock has started an empty mock server on localhost on port 8080. After you navigate to http://localhost:8080/__admin/ in your browser, you should get empty mappings entity: You can also change default port by adding --port...
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 >      ...
Read more