Testing RESTful services in ACCELQ

Testing RESTful services in ACCELQ

ACCELQ supports RESTful testing with features such as linking tests, parametrized variables, authorization, headers, and more. 

1. Linking tests - we can link multiple tests with one another. This means we can perform tests in a sequence. For example, we can make sure the login test case passes before we move on to buy a product test case.
    
2. We can also create tests that include both UI and API testing, thus giving us end-to-end complete testing. 
    
3. We can add parametrized variables - this means we don't have to hard-code the values of variables such as username, password, etc. ACCELQ can fetch them from databases, or from the results of previous tests.
    
4. Authorization- We can add authorization using Bearer Tokens, OAuth2, etc. to our REST API calls. We can also create connections in which we add multiple test cases. The authorization added to the connection will be used in all the test cases in it.

Flow of Testing of RESTful services in ACCELQ

There is a flow to testing RESTful services with ACCELQ that we must follow. It goes like this:

1. Create the Request
   
   1. Define REST connection.
      This is where we define the REST connection - the base URL, and the authentication headers. This base URL is attached to all the requests in this connection as a prefix. We must also set a connection name.
       
2. Invoke the Request
   
   1. Define Request
      Here we define the particular request we want to run. We define the URL (if there is a base URL, it will be prefixed automatically), the request method, as well as any additional headers.
       
   2. Prepare Payload
      If the request requires a payload, we add it here.
       
   3. Run the request 
      In this step, we run the request - and get the response headers, status, and body.
       
3. Verify the Request
   
   1. Verify Status Code
   2. Verify Response Headers
   3. Verify the Response Body 
       

Let's look at all the steps one by one.

Performing the RESTful API Tests in ACCELQ

Creating the Request

In creating the Request, we basically define the REST connection. It involves a few basic steps: 

1. Add the base URL for the connection. Typically, when creating tests - you would create a group of tests for a particular base URL. 
    
2. Add Authentication headers - if any authentication headers are necessary, we add them here. These will be used for all requests in this connection.
    

The command for the same is Define Rest Connection. It has the following parameters.

• Connection Name - The name for the connection.
• Url - the Base URL
• Authentication headers - Header name and value pairs, separated by commas.

Invoking the Request

Invoking the request has the following steps:

1. Define the request
   
   
   1. Add the Reference Name. This is the name of the request that we are creating. This is useful for referring to the request later. For example, let's say we have 2 chained requests, A and B. B uses some of the data we get in A. So, we will need a way to refer to A, which can be done using the Reference Name of A.
       
   2. Add Headers. Any headers for the requests also need to be defined. These may include application content, encoding, and more. 
       
2. Define Payload - If the request has a body (like a POSTrequest), it also needs to be defined. ACCELQ supports various payload formats - such as XML.JSON, Raw, and Form Data
    
3. Run the request
   A request that has been created can be invoked simply by selecting it and clicking the "Send Request" Method. 
   It can also be part of a more extensive test with a series of requests. This can be done using ACCELQ Actions.

The commands for invoking depend on the type of request. Let's see all of them. For all of these, the connection name must already have been defined.

Command for Invoking Get Request
The command name is Invoke ReST Request (GET). The parameters are:

• Connection Name - The connection name on which we will execute this request.
• Reference Name - The reference name for this particular request, used to refer to it later.
• URL - the URL for this request. If the connection has any base URL,it will be prefixed.
• Headers - Headers for this request, in the form of key-value pairs that are separated by commas.

Command for Invoking Post Request
The command name is Invoke ReST Request (POST). The parameters are:

• Connection Name - The connection name on which we will execute this request.
• Reference Name - The reference name for this particular request, used to refer to it later.
• URL - the URL for this request. If the connection has any base URL,it will be prefixed.
• Headers - Headers for this request, in the form of key-value pairs that are separated by commas.
• Payload Type - The type of payload data, for eg - application/json.
• Payload - The payload data.

Command for Invoking Post Request with Form Data Payload
The command name is Invoke ReST Request (POST) With Form Data Type Payload. The parameters are:

• Connection Name - The connection name on which we will execute this request.
• Reference Name - The reference name for this particular request, used to refer to it later.
• URL - the URL for this request. If the connection has any base URL,it will be prefixed.
• Headers - Headers for this request, in the form of key-value pairs that are separated by commas.
• Form Data- The payload in form data format.

Command for Invoking Put Request
The command name is Invoke ReST Request (PUT). The parameters are:

• Connection Name - The connection name on which we will execute this request.
• Reference Name - The reference name for this particular request, used to refer to it later.
• URL - the URL for this request. If the connection has any base URL,it will be prefixed.
• Headers - Headers for this request, in the form of key-value pairs that are separated by commas.
• Payload Type - The type of payload data, for eg - application/json.
• Payload - The payload data.

Command for Invoking Put Request with Form Data Payload
The command name is Invoke ReST Request (PUT) With Form Data Type Payload. The parameters are:

• Connection Name - The connection name on which we will execute this request.
• Reference Name - The reference name for this particular request, used to refer to it later.
• URL - the URL for this request. If the connection has any base URL,it will be prefixed.
• Headers - Headers for this request, in the form of key-value pairs that are separated by commas.
• Form Data- The payload in form data format.

Command for Invoking Patch Request
The command name is Invoke ReST Request (PATCH). The parameters are:

• Connection Name - The connection name on which we will execute this request.
• Reference Name - The reference name for this particular request, used to refer to it later.
• URL - the URL for this request. If the connection has any base URL,it will be prefixed.
• Headers - Headers for this request, in the form of key-value pairs that are separated by commas.
• Payload Type - The type of payload data, for eg - application/json.
• Payload - The payload data.

Command for Invoking Delete Request
The command name is Invoke ReST Request (DELETE). The parameters are:

• Connection Name - The connection name on which we will execute this request.
• Reference Name - The reference name for this particular request, used to refer to it later.
• URL - the URL for this request. If the connection has any base URL,it will be prefixed.
• Headers - Headers for this request, in the form of key-value pairs that are separated by commas.
• Payload Type - The type of payload data, for eg - application/json.
• Payload - The payload data.

Verifying the Request

This is the central part of testing RESTful services. We need to ensure that the response we receive from the API matches the one we expect. Majorly we need to match 3 things:

1. Status Code
   This is the HTTP response status code. These vary in different ranges. Status codes of the type 2xx indicate a correct response, 4xx status codes (such as the infamous 404) indicate a client error, whereas 5xx status codes indicate a server error. We can verify the status code returned with the expected status code using ACCELQ.
    
2. Response Headers
   Response Headers contain metadata, such as the date, server software, Content-Encoding, etc. We can set Header Names and their corresponding expected Header Values, and ACCELQ will verify them.
    
3. Response body
   The response body is an essential part of the verification. It contains the actual data sent by the server. We can verify certain parts of the data or the entire data. We can use functions like contains, equals, not equals, doesn't contain, etc. 

There are various verification commands. They are as follows.

Command to Verify Header from Response
The command name is Verify Header From ReST Response. The parameters are:

• Reference Name - The reference name of the request, for which we are running verification.
• Header Name - The header name we wish to verify.
• Header Value - The expected correct value of the header.
• Failure Action - The action to perform if the verification fails (continue the test or abort).

Command to Verify Status Code from Response
The command name is Verify ReST Response Status Code. The parameters are:

• Reference Name - The reference name of the request, for which we are running verification.
• Status Code - The expected correct status code.
• Failure Action - The action to perform if the verification fails (continue the test or abort).

Command to Verify if a Node in Response Matches Expected Text
The command name is Verify Node In ReST Response Matches. The parameters are:

• Reference Name - The reference name of the request, for which we are running verification.
• Match Type - The case sensitivity option  (ignore case, match case, or match with a regex pattern).
• Expected Value - The expected value of the text.
• Comparison Type - The method to compare (contains or equals)
• JSON Path - The JSON path of the value we wish to verify.
• Failure Action - The action to perform if the verification fails (continue the test or abort).

Command to Verify if a Node in Response Does NOT Match Expected Text
The command name is Verify Node In ReST Response Is Not. The parameters are:

• Reference Name - The reference name of the request, for which we are running verification.
• Match Type - The case sensitivity option  (ignore case, match case, or match with a regex pattern).
• Expected Value - The expected value of the text (that shouldn't match).
• Comparison Type - The method to compare (contains or equals).
• JSON Path - The JSON path of the value we wish to verify.
• Failure Action - The action to perform if the verification fails (continue the test or abort).

All of these processes can be automated and even linked with one another. We can link the response verification of one API to the creation of another API. We can perform different actions if verification fails and configure many more things using the ACCELQ platform.

Frequently Asked Questions

Why is automated testing necessary?

Throughout its development, software undergoes many changes. Code will be rewritten, changed, removed, and added. During this, it is essential to ensure that the code remains accurate, performant, and correct at all times. We use tests to do this, and if tests are run manually - they will soon get out of hand, as we won't be able to remember which tests need to be run in which order and which file requires which tests. Thus, automated testing can help in this by automating the process for us.

Do GET requests also have payloads?

No, GET requests don't have payloads. GET requests are used simply to fetch something from the server. We don't have to specify a body or parameters when fetching something. We only need to specify what we need to get and from where. For those, we use queries. E.g., if I want to fetch all the users from my website that are administrators, who have an age equal to 25, my API endpoint can look like this:
https://example.com/api/users?userType=admin&userAge=25

Thus, the URL itself specifies everything we need.A

Couldn't we just write custom scripts to manage automated testing?

It is possible to write custom scripts for everything, but the main point is that you will be wasting your time writing testing scripts - instead of the actual product. ACCELQ's sole purpose and role is to perform automated tests. Their platform will be more secure, performant, easier to use, and with a lot more functionality. With custom scripts, you would have limited functionality and hard-to-use tests.

Conclusion

This blog has explored what ACCELQ is and what testing REST APIs in it means. We have seen the flow of testing RESTful services in ACCELQ, and we have gone through the entire process step by step in detail.

We hope you leave this article with a broader knowledge of ACCELQ, RESTful services, and testing. We recommend that you explore our different articles on these topics as well, such as:

• Sanity Testing vs Smoke Testing
• What is ACCELQ
• Running Manual Tests in ACCELQ
• What is context and its creation in ACCELQ

You can practice questions on various problems on Coding Ninjas Studio, attempt mock tests, go through interview experiences, interview bundle, go along guided paths for preparations, and a lot more!

Keep coding, keep reading Ninjas.