5 tips to take your API testing with REST Assured on the higher level
It appears to be common amongst the test community to conduct functional testing using many libraries and frameworks that focus only on the User Interface (UI). Selenium combined with many programming languages, verifying all functional changes seems quite popular. It is certainly time-consuming because such tests need to open a browser in order to go through the User Interface. The amount of time required to open browser increases when we considering support for multiple browsers. Moreover, when writing test cases for UI, we write XPath or CSS selectors to grab WebElements in order to verify it, for instance, on IE or Edge browsers these selectors may behave differently than on Chrome or Firefox.
What is more, looking at the test pyramid we should keep in mind the number of tests being performed on each level.
When thinking about test automation, it is considered as a rather slow verification of an application through its user interface, which in turn increases build time. In terms of continuous integration and continuous delivery, it does not seem to be a proper approach. Do not make assumptions, I am not trying to say the verification of UI is not important.
It definitely is but requires performing a different kind of tests on a different level, keeping the number of UI tests as small as possible. This approach lets us introduce the term of ideal test pyramid into our project. The UI tests are good for regression and acceptance testing but there are other tests that provide better and faster feedback on the condition of application to the development team.
If we want to keep the feedback loop as short as possible, we need to select fast tests bringing the biggest value. Instead of executing a large amount of e2e UI tests, which are slow in most of the cases, it is better to try to move e2e tests to API level and use UI tests only to verify the correctness of UI. Such an approach helps us to save a huge amount of time while building and testing project. For instance, in the one of a project that I worked, running e2e UI tests took 15 minutes when this group of tests was reduced. When I covered reduced scenarios on the API level, execution time decreased to 3 minutes. There are plenty of API testing frameworks available that allow conducting API testing. You can use postman and quickly automate collection usually provided by developers as documentation. You can use a simple HTTP client library and build your own test framework for testing API. Or you can use existing libraries like REST Assured and then write your own testing framework. Using REST Assured has a huge advantage — it is ready to use the library which has huge community support and with it, you can build a framework for your project needs. It is a less time-consuming way than writing an entire framework from a scratch. Moreover, such a framework can be used in other projects that are developed within your company.
In the following article, I will not focus on the basics of REST Assured but will share useful tricks and solutions speeding up the process of writing your tests. In order to grab basic information related to REST Assured and get to know how to start, go to the official RA page.
Hints for test writing
REST Assured allows users to handle HTTP request and can be written in a quite readable format. You will find a simple test below which is to check if we get 200 status code for given GET request.
Taking only simple parameters into consideration, such as the limit of displaying the number of articles or checking only response code, the abovementioned test case seems to be easy.
Create POJO/wrapper
What happens, however, when the amount of test cases increases and we want to test something much more complicated than just trivial response codes?
The best idea is to introduce wrapper for HTTP request methods. It simplifies coding a lot and makes our code reusable. Reusable methods help you in writing tests faster and, most importantly, they make your code easily legible and maintainable.
Above methods can be used in many test cases which results in a more generic approach to writing tests.
In the above addUser() method we create a user. In this method, we pass user data in order to create the user in our database. There are many ways to create data and pass it through proper request as a body. You can create HashMap and parse it to request the body. Another way is to create proper JSON parser and send data as JSON format.
Use Lombok
In my opinion, the best and quickest way to do this is to create POJO objects. It makes our code clean and reusable. With the help of Lombok plugin, which can be added to IntelliJ, creating such an object is very simple.
In order to do that, few annotations should be added to the code:
Lombok generates setters for you, thus you do not need to spend time on writing correct setters and getters. Adding @Accessors() annotation helps us to create fluent setters which simplify the code and make it more readable.
Our test methods look quite clean and short. We create a user object and pass it to the generic method we have created before.
Please keep in mind that a password is not passed as a readable parameter. This value is taken from system environment variables which makes our test more secure.
For better code legibility and maintenance, I have also created an enum EndPoints which stores all URI paths. I have also modified the code a little bit. Hence, if we do not use any other endpoint in addUser() method now, we can hide the path parameter so our code would look like in the example above.
Use AssertJ
Going back to our test method, let’s have a look at it! Right now, it does nothing more than creating a user as an object and passing it to the endpoint. Moreover, it does not check whether a request was executed with any fail or success, whether not.
In REST Assured, there are built-in assertions that allow us to check if, for instance, the status code we expect is, in fact, the correct one.
However, I would recommend using AssertJ library for all kind of assertions as it appears to be very easy to use. AssertJ has many incredible methods helpful in making assertions.
With AssertJ our test method would look like in the below example:
AssertJ has many useful methods verifying necessary data in a convenient way. Proper logging handler can even lead us to throw information to our logs that assertion has failed without reading and displaying a complicated stack trace.
These three simple tricks helped me to speed up writing tests in the project I have been engaged. There are many other things that may help you in writing tests, nevertheless, everything depends on your current needs, kind of tests and project you are working in.
Categorize your tests
Try not to write test cases into one test class. You may think that keeping test cases in one place might be a good solution. However, it appears a challenge when having a huge list of test scenarios you need to cover and you look for one specific test in one class.
The developers with whom you work in the project are likely to store their documentation in tools such as Postman or Swagger when working on creating API. In order to look for a proper endpoint, each collection of endpoints should be divided into the functional category.
Try to do the same with your test — group them by category, and keep each functional category in a separate test class.
Add fancy test reporter
There is no worse thing than going through badly written logs or lack of logs at all. In this case, debugging becomes a nightmare. In order to make your life easier and to save your time when thinking of errors in code and of test steps, make an attempt to describe each and every step you perform. Especially, when your test collection is growing. If you are a fan of simple text report after each test execution, I recommend adding Apache Log4J logger to your code. If you or anyone in your team is a fan of nice test report with beautiful charts illustrating failed and passed tests, I suggest using Extend Report library then.
Is it worth it?
One of the advantages of testing application with API testing is the option of checking it, even if UI is not ready. You can quickly provide feedback to the development team or business holders on the quality of the application condition. When errors or bugs are detected, they can be fixed faster — at an earlier stage of development.
API tests performed manually or automatically are quicker than UI tests. Tester does not need to go through the entire UI to verify functionality. Responses for the request can be received faster since there is no need to wait for the UI.
Although, testing API with REST Assured has as many advantages as limitations.
Validation of all parameters within a request might be challenging. You cannot check only status code and be 100 % sure everything is working fine. You need to ensure that all parameter data uses the correct string or numerical data type and passes other validation criteria.
It is very common that API calls need to appear in a specific order to work properly. In result, this might be difficult for a tester who has been working on different kind of tests so far.
Despite many advantages of API testing, it is very common that these kind of tests are missing in our tests scope. Why is that? Probably, due to the lack of knowledge in that particular area of testing, lack of time for API test writing or both. I strongly suggest adding API testing into test scope. This move should be done when preparing the test plan and the test strategy for our project. If you are currently involved in a go-live project, you should encourage your team to develop such tests. It will bring additional value to your test scope and it will boost your knowledge about the application. Your team will have quick feedback about the condition of application and build time will decrease.
Conclusion
While testing your API you can verify your application on many levels. Test cases you have written can be used not only for functional testing but also for security, load or performance testing. With the help of REST Assured library, you can write a test in a quicker way and you can detect bug at an early stage of development. Although, you need to keep in mind that API tests and UI tests are not all tests that your team should perform in order to keep a good quality of the application. There are other levels of tests that are pointed out in the test pyramid and your team should focus on, for instance, unit and integration tests.
To sum up what has been told so far:
- Try to keep your test cases clean.
- Group test cases by functional category.
- Add fancy test reporter to read test result easily.
- Use POJOs object in order to handle test data.
- Use AssertJ library for validating data or any other fancy library that you prefer.
- Try to wrap up methods that can be reused in other test cases, do something like creating Page Objects in UI testing.
- Use the Lombok plugin for creating setters, getters methods and fluent setters.
