I just realised that the announcement for my blog series on “Testing under the bonnet – What you see ain’t all there is” was in June this year. So as the year is coming to an end I would like to start, a bit delayed though, with the first blog post on this topic.

Automate your RESTful API

When we started our new project I was lucky enough to be the Tester/Testmanager on an Agile Scrum team. From the very beginning I was involved in discussions, planning and development of the product for our client. We decided to use a RESTful API on the backend and I immediately thought about the Agile Testautomation Pyramid. What I was not sure about was the tool to use. First of all I thought about SoapUI. However that was not flexible enough for me. As I have got a development background I was looking for a more technical tool. So I came across a library called rest-assured.

What’s the benefit of automating your RESTful API

Let’s start with some words about the benefits of automating your service API.

Way too often we focus only on the visible (GUI) and completely neglect all there is on the backend of a system. When we test only on the UI level it is hard to tackle some special cases like exceptions and backend validations and it is much slower too.

By automating tests/checks on the service level we can run a lot more tests within a shorter period of time. Whenever we check in some new code we automatically deploy to a test environment. After the deployment the service tests run. This whole cycle takes about 10 to 15 minutes. So that’s quite a fast feedback loop compared to testing everything manually.

Some examples of tests/checks we run are

• get content when logged in
• get content when logged
• get content with missing parameters
• get content with wrong parameters
• etc.

You can see that there are a lot of good checks that will take up a lot of time when you have to do it manually over and over again.

REST-assured

I’ve already mentioned that we decided to use a library called rest-assured to automate the service level tests. One reason for this tool over SoapUI was that it is more technical. Meaning that is is more technical it was not only for my own benefit. I was also thinking about the developers on the team. From my experience it is easier to convince developers to write acceptance tests when they can do it in their own language – Java. Developers tend to avoid tools like SoapUI where they have to click around a lot.

What’s so special about REST-assured?

REST-assured is quite handy to use and it also comes with the Gherkin language to support a Behaviour-Driven-Development approach.

A simple test with REST-assured looks like this:

given()
  .header("Authorization", "Basic " + configuration.basicAuthToken())
  .header("Accept", "application/json")
  .parameters("grant_type", "password", "password", "password", "username", "username")
.when()
   .post(configuration.loginResource())
.then()
   .statusCode(200);

Conclusion

As a conclusion I have to say that I am quite happy with the decision we made. The service automation with REST-assured integrated into the build pipeline gives us fast feedback after a code change. Additionally it helps us to better identify issues. We know that when the service tests pass there is a high probability that a found problem during exploratory testing is caused by the JavaScript front-end.

And in the end it gives us confidence about what we do and what we deliver to our customer.