In this series of REST API Automation Testing Framework tutorial, we will learn to build the automation framework to test the REST API from scratch. We will be using the Live Project which is BookStore API provided by ToolsQA. We will write out tests in BDD format using Cucumber and for API interactions we will use Rest Assured.
REST API Automation Testing Framework with Cucumber & Rest Assured
Rest-Assured is a Java-based library that is used to test RESTful Web Services. The Rest Assured Library provides is a domain-specific language. This helps us to write powerful and maintainable tests for RESTful APIs using Rest Assured. It was designed with the focus on easing the tests as well as validating the REST APIs. REST Assured Library can be integrated with JUnit, TestNG and Cucumber frameworks to write test cases. It supports types of request methods such as POST, GET, PUT, DELETE, HEAD, PATCH and OPTIONS to verify the response of these requests. It is one of the most popular libraries which is highly used in API Test Automation.
The first step to build an API test is to understand it’s documentation. This chapter takes you through a simple explanation of every component in an API document. It discusses Why do we need API documentation? What is the API documentation? How to use an API document? It illustrates all of this with the help of an example in Swagger. Moreover, it talks about the various types of API tests depending on the context. This chapter serves as a ground laying to our next chapters of building an API Automation Testing Framework.
This chapter is to define the End To End Test Scenario we will build for our API Automation Testing Framework. We hit the ground running with the basics of Rest Assured, Cucumber, and Maven. We effortlessly work our way up with the required installations and a primary end to end the flow of the REST API Test with the selected test scenario. Additionally, we trigger the tests once they are build to verify the test scenario we automated. This reinforces our confidence in the basic structure we have built until now for our API Automation Framework in Rest Assured library
Now that we have built our REST API Test, it’s time to convert our test into the coveted Cucumber BDD Style Framework. Foremostly, We will add the needed cucumber dependencies for it. Secondly, we will go about writing the tests to a feature file and move our end to end API test code to Steps class file. Finally, it’s showtime. We will run our Cucumber tests in various ways such as through command prompt and as Junit tests to make sure everything is working fine as expected.
So far we have been sending the request body in the raw format for our Requests. It’s error-prone and non-maintainable. We need to send the request body as an object. We will use the concept of serialization and de-serialization to convert our request bodies into an object. The Rest Assured library depends on the Jackson (Databind) library, to do this work of Serialization.
In this chapter, we are converting the JSON Response Body to POJO. Until now we used JsonPath to validate parts of the Response body. We created POJO classes for our response objects in this chapter. In the end, we modified the Steps class as per the changes we made and triggered our tests. Lastly, with the changes we did, we are triggering our cucumber tests to confirm if the tests pass or not.
For this chapter, we will work on the Separation of Test Layer with API Services and take a step further to make our tests cleaner and maintainable. The test layer needs to focus only on the test data (parameters) sent in the request and receive responses from the APIs. It should not be focused on the heavy logic of the internals of API implemented. The code duplication due to the Building RequestSpecification object, adding headers and making calls to the server is avoided by this.
As a part of the implementation of REST Routes for this chapter, we will keep all the routes at a single place. Wherever the routes are required, we will use it from this Routes class we created. The advantage it gives is that suppose any of the route changes. We won’t have to make changes everywhere. In other words, we will place them in a single place in the Routes class. With these implementations, we ran the Cucumber as well as Junit tests to ensure nothing has broken.
We are dealing with the response objects of various data types such as Token, Books, and User Account. Moreover, one can build these response objects fail-safe by using generics. Generics adds a layer of abstraction. In addition to that, they add a way to specify types for classes and methods. Thus, in this chapter, we are implementing an interface capable of handling different response objects. To provide this parameterized value to a parameterized type, we implement this as a Generic Interface in this chapter.
We are sending the BASE_URL, the headers in every method, as we call our methods in the Step Definitions. It leads to us creating the RequestSpecification object again and again when it is the same for every step. It would be simpler if we created this once for all the steps. Thus in this chapter, we are refactoring the request headers.
In a Test Scenario in Cucumber a series of steps in which they get executed one after one. Each step in the test scenario may have some state which can be required by other steps in the scenario. Cucumber supports several Dependency Injection (DI) Containers – it simply tells a DI container to instantiate the step definition classes and connect them up correctly. One of the supported DI containers is PicoContainer, which helps in sharing the context between steps.
Scenario Context is a class to hold the test data information specifically. It uses the Test Context to travel the information between various steps. With the ScenarioContext class, you can create any number of fields to store any form of data. It stores the information in the key-value pair and again, the value can be of any type. It can store String, Boolean, Integer or a Class.
This chapter is about implementing a configuration.properties file for our Rest API Automation Testing Framework using Cucumber. It is against clean code practice to store hard-coded values in the project. With the help of this properties file, we will be eliminating the usage of hard-coded values for our framework. Singleton pattern ensures we create only one instance of a class in the JVM. Moreover, it enables a global point of access to the object. In our case, we have ConfigReader.java, which should be accessed globally. So we made the ConfigReader.java class as a singleton.