Api Automation, Rest Assured, Non-BDD
How to start a Rest Assured Project
I’ve been working on backend projects for 4 years and I realized the most crucial factor is setting a good structure in a test automation project. After writing a code to test your aimed scenarios without any structure, it may be too late to fit them into a good one. In this article you’ll see a sample of a well-structured non-bdd project.
Let me show you what I found out!
Used library/language/framework -> Of course Rest Assured:) Java, Maven
Used sample api service -> https://petstore.swagger.io/
Starting with an instance structure.
From top to bottom we’ll see the usage of directories:
1- Client: includes general Rest Assured api call methods (HTTP Methods: Get, Post, Put, Patch, Delete) to avoid retyping the same codes in our step classes or helper classes. Let’s see an example of a simple GET method below.
2- Enums: includes definitions for collections of constants to use in test or helper classes. For instance, you may have a product priced differently but all other information is the same as a test data. In this case you can create a product enum and define details as below.
3- Models: includes the POJO(Plain Old Java Object) part of the project. We’ll store all of our request or response body objects in this directory. In order to get and set our request properties, the Inner Builder plugin can be used as an easy solution. The builder design pattern provides constructing complex objects by avoiding to create multiple object classes related to each other and it helps us to build our response body objects in the same class. You can define your constant properties in your class or you can manipulate them with the help of the builder in your helper class or test class. Let’s see a POJO request sample within pet properties:
And the other sample class as a response object below. Jackson library is preferred to serialize the response body objects considering that our restful api services mostly return a JSON object. Additionally, the POJO generator plugin can be used to generate response classes easily.
4- Utils: includes assistive classes to manage complexity. For instance, we have properties in our project, and if we want to use some data from the property file, we should have a PropertyManager class to get data with the help of a getProperty method.
In Test directory
5- Config: includes some constants like URLs or Errors.
6- Helpers: includes methods to call api endpoints. This directory can be seen like a steering wheel by considering its relation between test classes and Rest Assured Client (http methods). Here is a simple post example for a Create Pet test case:
7- Services: includes all test classes inside of a tailored directory for api service. See this Create Pet Test as an example:
8- Properties: includes some configurable parameters or simple test data. For example, you may want to store device information for usage in all test cases related to this device.
In a nutshell, our structure was constructed decently by taking into consideration maintainability and readability. Besides that, we of course have to follow some code rules to ensure other automation developers comprehend our code or implement new code swiftly!
As you can see, I like using Rest Assured to automate backend tests. I’ve experienced automating with Postman and Karate as well. However, they had some disadvantages with performance etc. After the implemented complex services’ api automation tests, using the above structure and tools gave me a very efficient output. :)
How about your experience with Rest Assured? Do you prefer a bdd or non-bdd structure? Please feel free to comment so we can learn from each other! :)
