API Testing in TOSCA

 API is the shorter form of Application Program Interface. It’s working as an interface which allows two applications to communicate with each other through common message formats such as, XML, JSON, etc.

Assume, we have four different applications – SAP App, Mobile Apps, Web Portal and Billing System, which are integrated by common interface as API. Here API is working as an interpreter. Each of the system interacting with each other by sending an API request and receiving the API response. Basically, each system is communicating with API and based on the request, API routes the messages to the target system.

Purposes of API:

• Communicate between different applications.
• It’s platform-independent.
• Development of one system is not dependant with another.
• Fast and secure communication.
• Easy to integrate many applications.

Types of API:

REST API (Representational State Transfer): It’s a web service API which is now an essential part of modern web-based applications such as, Facebook, Netflix, etc. REST API should comply with below standards.

• Stateless – It does not allow to store the data they received from a requestor.
• Client-Server Architecture – Client and Server’s REST APIs should be independent with each other.
• Cache – The cache is storing the browsing data for a specific period of time.
• Uniform Interface – Communication should be HTTP requests using URL, CRUD(Create, Read, Update, Delete) and JSON.
• Layered System – REST APIs should use different architecture layers which contributes towards a clear hierarchy.
• Code on demand – It’s an optional rule to transmit code within the application through the API.

RPC API (Remote Procedure Call): These are the simplest API which is used from old days. The aim of RPC is to execute code on the server system. It was easier for application developers to develop applications involving more programs or services in the RPC API.

There are two types of RPC APIs – XML-RPC and JSON-RPC.

SOAP API (Simple Object Access Protocol): It is also one kind of web API. SOAP is the first to define the process about the applications to use a network connection to manage services. It’s a special protocol which is defined by the World Wide Web Consortium (W3C).

API Testing in TOSCA:

The API Testing is an approach to test the API components of any software product in efficient way. To perform API testing, we need to validate the API response received based on the API request. The main moto of API testing is to test the core functionality, reliability, performance and security through the API. API Testing is ideal for testing the core functionality of the application when the all the application is partially developed. So, it allows us to start the testing before the integration of the software components.

The goal of API testing is to ensure that the core functionalities of the application work as expected without interacting in the UI layer. To perform the API Testing, always, we need to take help from any third party tools like Postman, UFT, TOSCA, etc.

Here, TOSCA is one of the best automation tools for API Testing.

Benefits API Testing in TOSCA:

• API testing can be used to validate the core functionalities even when the UI hasn’t been developed/modified. Hence testing can be initiated much before actual functional testing (UI based) is done.
• Frequent application changes can be tested quickly. 
• It is easy to maintain test cases in TOSCA.
• The API testing in TOSCA can be done much faster.
• Standalone Tosca API Scanning Wizard is available to scan the API in the easiest way.
• Easy to create Tosca test scenarios.

Supported Standards for API Testing in TOSCA:

Web Service Standards	SOAP 1.1, SOAP 1.2, REST
Transport Layer	HTTP 1.1, IPv4, IPv6
Message Format	XML, JSON
Message Description Language	OData 4.0, SWAGGER, WSDL 1.1, WADL, XSD, JSON Schema
Authentication	Basic Authentication, Kerberos/SPNEGO, NTLM

Process flow for API Testing in TOSCA:

API Services – Identify the API details and functional flow for automation.

API Scan – Scan the API and create Tosca modules.

Create Test Case – Generate test cases and perform cleanup with parameterization.

Run – Execute the test cases and share the reports to stack holders.

Step by Step Guide to Perform Automation of API Testing in Tosca:

Step1# Collect API Details – We need to collect below API Information of the sample application,

• Endpoint: http://webservice.toscacloud.com/rest/swagger/docs/v2
• Credential: Username1/Password1
• Web Service Standards: REST
• Message Format: JSON

Step2# Identify Scenarios and data formats for the API Request.

Test Scenario – After logging into the sample swagger application, need to add a new coffee brand and verify.

Data Format – Data need to be passed through JSON format.

Step3# Manually Verify the scenario using tools like TOSCA.

Step4# Scan the API with the endpoint reference. 

1) Open the API Scan wizard from “API Testing” tab available in TOSCA Header section.

2) Click on URI button and enter the endpoint address. Now click on OK to start scanning.

3) After a few moments, API scan will be completed, and scanned API modules are displayed in the API Scan Wizard.

Step5# Create modules and test cases – Selecting the root folder, i.e. “Swagger Demo CoffeeShop V2”, click on “API Test Case” to generate modules and test cases in the TOSCA. For every transaction, there are two parts – one for request and another for the response.

Step6# Cleanup scenarios: Auto-generated test cases can be used as a base suite which needs to be cleaned by removing the unwanted folders, create module attributes to parametrize the response values such as, authentication token which will be required to perform any transaction.

Post Coffee (Modules for API Request) –

After assigning the parameters, the API Test Case will look like below.

`

Step7# Execute API Test Case in TOSCA – First of all, we need to add the newly created test case into the execution list. Now, the execution can be initiated by clicking on “Run” button. As it’s an API Testing, no application UI will be visible through out the execution. After completion of execution, Report will look like below.