A Java Check Automation Framework for API Testing

On this article, Oleksandr Podoliako shares with us some insights of expertise in writing a take a look at automation framework to check API with Java.

Writer: Oleksandr Podoliako

Lately, I’ve obtained a take a look at activity to put in writing a take a look at automation framework for API testing with Java. I believe it might be attention-grabbing for others and I wish to share the outcomes.

The framework was written with Java. Maven, Lombok, testNG and Relaxation Assured have been additionally used. The framework consists of purchasers and take a look at layers. If the checks are deliberate to be E2E or the enterprise logic is difficult, then a enterprise layer, which comprises a number of API purchasers, might be added. Additionally, you could possibly additionally add a Cucumber layer.

The primary concept is to generalize the bottom API consumer, which comprises primary fundamental API strategies (GET, POST, PUT and DELETE). This offers us a chance to make use of one consumer to interplay with nearly all endpoints. Additionally, it permits configuring the Relaxation Assured log in a single place by means of baseAPIClient.

public class BaseAPIClient {
   //some code was reduce

   public <T, Ok> ResponseWrapper<T> getEntity(Class<T> t, RequestWrapper<Ok> requestWrapper, String url) {
       ResponseWrapper<T> responseWrapper = new ResponseWrapper<>();
       Response response = configureRequest(requestWrapper)
               .when()
               .get(url);

       responseWrapper.setBody(response.as(t));
       responseWrapper.setResponseRaw(response);

       configureResponse(responseWrapper);

       return responseWrapper;
   }

   //some code was reduce

   non-public <T> RequestSpecification configureRequest(RequestWrapper<T> requestWrapper) {
       RequestSpecification requestSpecification = RestAssured.given();

       change (logRequest()) {
           case "all":
               requestSpecification.log().all();
           case "parameters":
               requestSpecification.log().parameters();
           default:
               requestSpecification.log().methodology();
       }


       if (requestWrapper.getHeaders() != null) {
           for (String key : requestWrapper.getHeaders().keySet()) {
               requestSpecification.header(key, requestWrapper.getHeaders().get(key));
           }
       }

       if (requestWrapper.getQueryParameters() != null) {
           for (String key : requestWrapper.getQueryParameters().keySet()) {
               requestSpecification.queryParam(key, requestWrapper.getQueryParameters().get(key));
           }
       }

       return requestSpecification;
   }

   //some code was reduce
}

Two wrappers, which have been generalized, have been created to have a unified method. RequestWrapper and ResponseWrapper get their varieties in checks. Additionally, they comprise uncooked knowledge from the Relaxation Assured.

@Getter
@Setter
@Builder
public class RequestWrapper<T> {

   non-public Map<String, String> headers;
   non-public Map<String, String> queryParameters;

   non-public T physique;
}

@Getter
@Setter
public class ResponseWrapper<T> {
   non-public T physique;
   non-public Response responseRaw;

   public int getStatusCode() {
       return responseRaw.getStatusCode();
   }
}

BaseAPIClient can be utilized to work together with completely different endpoints. Nevertheless, I like to recommend making a separate consumer for each endpoint, which inherits from BaseAPIClient primary performance. Separate API purchasers might be expanded with particular API strategies like search and filter. Base API methodology from BaseAPIClient may be overridden.

public class PostsClient extends BaseAPIClient{
}

I help the concepts of isolation and managing state of utility. You possibly can learn extra about this in my earlier article (Automated Testing Ideas). I encourage you to create and take away take a look at knowledge in earlier than and after strategies. It would improve checks reliability.

@BeforeMethod
public void init() {
   postsClient = new PostsClient();
   softAsserts = new SoftAssert();

   Put up submit = Put up.builder()
           .userId(1)
           .title("title")
           .physique("physique")
           .construct();

   RequestWrapper<Put up> requestWrapper = RequestWrapper.<Put up>builder()
           .headers(HEADERS)
           .physique(submit)
           .construct();

   responseWrapperPreconditions = postsClient.postEntity(Put up.class, requestWrapper, URL);
}

@AfterMethod
public void cleanup() {
   RequestWrapper<Put up> requestWrapper = RequestWrapper.<Put up>builder()
           .headers(HEADERS)
           .physique(responseWrapperPreconditions.getBody())
           .construct();

   postsClient.deleteEntity(Put up.class, requestWrapper
           , URL + responseWrapperPreconditions.getBody().getId());
}

I like to recommend writing take a look at, which cowl one REST methodology, in a single class as a result of the preconditions are difficult and may be completely different for each REST methodology. Additionally, I like to recommend grouping a number of asserts in a single take a look at methodology due to optimization. The extra atomic method is legitimate.

@Check
public void testGetPosts() {
   RequestWrapper<Put up> requestWrapper = RequestWrapper.<Put up>builder()
           .headers(HEADERS)
           .construct();


   ResponseWrapper<Put up> responseWrapper = postsClient.getEntity(Put up.class, requestWrapper
           , URL + responseWrapperPreconditions.getBody().getId());

   softAsserts.assertEquals(responseWrapper.getStatusCode(), 200
           , "Response standing code ought to be 200");

   softAsserts.assertTrue((isJsonSchemaValid("postsGetSchema.json",
                   convertToStringJSON(responseWrapper.getBody())))
           , "The search returns response with invalid json schema");

   softAsserts.assertEquals(responseWrapper.getBody().getId(), responseWrapperPreconditions.getBody().getId()
           , "Response id ought to be appropriate");
   softAsserts.assertEquals(responseWrapper.getBody().getUserId(), responseWrapperPreconditions.getBody().getUserId()
           , "Response userId ought to be appropriate");
   softAsserts.assertEquals(responseWrapper.getBody().getTitle(), responseWrapperPreconditions.getBody().getTitle()
           , "Response title ought to be appropriate");
   softAsserts.assertEquals(responseWrapper.getBody().getBody(), responseWrapperPreconditions.getBody().getBody()
           , "Response physique ought to be appropriate");
   softAsserts.assertAll();
}

This take a look at has a presentation aim and is being failed as a result of the testing API utility doesn’t truly create and take away entities.

The complete code may be discovered on GitLab

In regards to the Writer

Oleksandr Podoliako has been working in numerous software program tasks as a take a look at automation engineer since 2017. His primary know-how stack is the Java stack. He has handed greater than 5 IT certifications. He has written a number of testing associated subjects and has carried out greater than 30 interviews in numerous languages with candidates from everywhere in the world.

This text was initially printed on https://oleksandr-podoliako.medium.com/test-automation-framework-for-api-testing-with-java-ffd80259fe87 and is re-published right here with permission.