Skip to main content

Building microservices testing framework

RESTful services and microservice architecture in general are big trends in the industry right now. I’ve noticed it also from this blog’s traffic analytics, where topics related with REST testing get the highest interest. Therefore I’ve decided to create some kind of example framework for RESTful APIs functional testing. Project is based on REST-Assured as a services client, Spock as a testing framework, Groovy and Gradle. You can clone full repository from my github. Tests are run against Wiremock API described in this post. Please consider this project as a kind of bootstrap, since it’s an example, not full-blown test framework. Ok, so as Linus said – talk is cheap, show me the code!


Usually, first thing for me after importing new project is opening build.gradle (or pom.xml, in case of maven). In our example, the most important dependencies are REST-Assured and Spock. We’ve also Jackson, for serializing objects, Logback for our logs and snakeyaml for reading .yaml files, where we’d store properties. Let’s see the whole file:

Besides dependencies, interesting part here is testLogging.showStandardStreams = true property. This flag gives us ability to print log entries in stdout, which I find helpful in test debugging. 

To have a greater understanding, let’s have a look at the project tree also. I’ve divided files into context packages, so we have: testflow package, with our test classes, next there is service, with api’s clients, dto and factory, with our entities and their builders, asserts with custom assertions and utils with yaml reader. There is also resources folder, where we store logback configuration and test.yaml with our properties and constants:

Test class 

The core of our framework are testing classes in testflow package. Since it’s an example project, we have only one test (in TestCaseExampleSpec class):

Our test case is super simple – we build request with new user, post it to webservice, and then validate response. Since we’re using Spock, test steps are in BDD convention. You could noticed that test class extends another – For those who are not familiar with Spock, it’s for overriding default configuration. Every test class in Spock have to extend Specification class, and if we want to add some custom properties or setUp methods, We have to extend Specification and then extend out test classes:

Here, we’re setting up logging rule with test names, configuring default timeout, and setting up REST-Assured to use some less restricted https validation.

Service layer 

Service classes are the engine of our framework. We’re storing here clients for our REST APIs. With use of REST-Assured, we’ve created following client:

I’m not going to dig down into details of framework. If you want to learn some more, you can view my past articles: REST-Assured: framework overview and REST-Assured: going deeper. In simple words, we get host of webservice under the key which we’ve declared in test.yaml file and post User entity to /addNewUser method. Then, we validate if response code was 200 and return response as a Map.

Entity and Factory 

Entity, yes – no magic here. We have two properties:

Next thing is a UserFactory, where we build our entity. For the sake of test readability, I’ve created custom method buildNewUser() without any arguments, and then I invoke factory method and pass arguments to it. User login and www values are taken from test.yaml file, where we store them:


If you’re familiar with REST-Assured, you can ask why we’ve created separate package with assertions, instead of doing them directly in service client methods. We could do that, but I prefer to be independent from specific frameworks as much as I can. Another point is possibility that we’d want to have some more complex assertions in the future. Therefore we’ve created UserValidation class, where we validate responses returned from our services:

Since it’s only example, we’re checking presence of login property only and it’s value. Although, validation classes would be ideal place for some serious validation and assertions.

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


My idea behind this post was to provide you some ideas for creating your own REST testing frameworks. We’ve omitted some parts of the project, like logback configuration or yaml reader – that’s because I found them less crucial. I encourage you to clone whole project from my github and to play a little with the code. 

As a fan of continuous improvement, I’m sure that lots of you would have some thoughts and improvements for the code and idea of the project, so I hope that you’d share them with me in the comments!

Popular posts from this blog

REST-Assured framework overview

In modern software development, REST services becomes most popular choice for implementing distributed and scalable web application. They are light and easy to maintain, which results in faster and more effective implementation and system integration.
I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks: REST-Assured: going deeperBuilding microservices testing framework
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. In this post we will get our hands dirty and write automatic test in Rest-Assured framework.
In order to create complete implementation of automated tests in Rest-Assured framework, we need to write our code against some example API. We’ll use standalone Wiremock m…

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 an API call is synchrono…

Notes after TestingCup 2018

On May 28-29th I attended TestingCup conference in Łódź. Having quite unique perspective: this was my second year in row as a Speaker at this conference I want to share some thoughts on the event. Dust has settled, lets go! 

Championship Originally TestingCup is a software testing championship. Wait, what? Yes, the formula is unique: teams and individuals from all around Poland are competing in finding the most bugs and defects in specially prepared application - Mr. Buggy. I don’t have specific data, but since this year’s conference was all english I guess competitors were not only from Poland. As a spectator, I must say that the whole competition looked very professional. There were team shirts and names, podium and trophies (gold cup and cash). 
Some cons? Testing championship is held at the first day of the conference. So this is already a conference, but if you’re not taking part in the championship… there’s not much to do, since all the talks are in the next day. Organizers are aw…