ReadyAPI helps Agile, and DevOps development teams improve API quality by allowing them to manage and run automated functional, security, and performance tests through a single centralised interface. ReadyAPI empowers software teams to share testing projects and artifacts, report and fix errors straight from the testing IDE, and distribute licences among team members.
This blog explains the details of Settings in Ready API along with the details of Authentication, Behavior Settings, and Coverage Settings in Ready API.
Without further ado, Lets get started.
Authentication
You can set up authentication options for your service on the Auth page of the virtual service editor.
Working
In the actual world, authentication protocols establish connections between servers and clients using unique headers and unique techniques. Virtual services in ReadyAPI don't mimic these intricate situations. A virtual service merely determines if a request's Authorization header begins with a value that corresponds to the authentication type you selected on the Auth tab. The service handles the request in accordance with the dispatch or behaviour settings if the request includes the Authorization header and that header begins with the proper string. The service returns the 401 Unauthorized error and does not process any additional responses if the request does not have an Authorization header with the proper text (Example: It ignores the Errors behaviour settings).
Configuring Virtual Service Authentication
The steps to Configuring Virtual Service Authentication are as follows:
Choose the preferred authentication type on the Auth page of the virtual service editor. The Header and Starts with edit boxes will be shown in the editor.
Add the Authorization header as a custom header to the requests if you're planning to utilise ReadyAPI to simulate requests.
You must take into consideration the following points while Configuring Virtual Service Authentication:
Add an assertion to your request if you want it to fail when it encounters the 401 Unauthorized error. By default, the test case execution does not stop when the virtual service returns this error.
Virtual services do not handle incoming requests if permission fails. This implies, for instance, that your service's Errors behaviour settings will be disregarded.
When queries come from localhost, real web services that use the SPNEGO/Kerberos authentication type frequently forego authentication. Since you will be using SPNEGO/Kerberos authentication to deliver requests to your virtual service, we do not advise using localhost in the URL. Instead, use a Service Principal Name (SPN), which is typically the server name or IP address.
Let's dive into the details of the behavior settings.
Behavior Settings
You can set up several aspects of how the service functions, such as network bandwidth, error simulating, and other things, on the Behavior page of the virtual service editor.
REST and SOAP services are the only ones that use the Hardware, Network, and Errors parameters that are explained below. JMS virtual services use other options.
Hardware
To simulate the performance of the computer where your virtual service will run, use the Hardware parameters. By choosing one of the Server Capacity choices, you can select predetermined numbers or entirely new ones:
You may simply specify the machine performance using the Server Capacity options, which range from S (lower performance) to XL (powerful server). The proper values for the Min Threads, Max Threads, and Response Delay edit boxes are displayed when an option is chosen.
Network
To alter the network bandwidth, use the network settings. The following settings are included in this section:
Errors
You can use the parameters in the Errors section to mimic errors in your virtual service's work. For instance, by altering these settings, you can create a scenario in which your service responds to any request with an error following a time of successful operation. You can optionally set a time limit for the "malfunctioning," following which the virtual service resumes "regular" operation. This will enable you to examine how the client software responds to a brief time of service interruption.
You can simulate error responses for the entire service using these settings. It will respond to any request using these settings. Configure the dispatch parameters if you only need to mimic error answers in response to specific requests.
The following parameters are found in the Errors section:
JMS Behavior
Only three behaviour settings are used by JMS virtual services. You must utilise scripting or your JMS provider's functionality if you require more complicated behaviour.
Let look into the details of Coverage Settings.
Coverage Settings (SOAP Virtual Services)
Each SOAP virtual service has a WSDL standard that outlines the requests and answers it can handle. A virtual service can be instructed to examine incoming and outgoing communications in order to determine which communications were handled while the service was running. This aids in estimating how effectively the WSDL definition for your web service is covered by your virtual service and your testing. You can view coverage results on the Coverage page of the SOAP service editor after enabling the coverage check for the SOAP virtual service. SoAP virtual services are the only ones that can access the page. In addition to service coverage, ReadyAPI also allows you to assess coverage for specific messages. On the other pages of your virtual service editor, you can accomplish this using the details provided below:
Enable Virtual Service Coverage
The coverage check is not enabled by default. Check the Enable Coverage box on the Coverage page to make it active. Before or during the service run, you can check the box.
You can start your virtual service from within ReadyAPI (if it isn't already running) after checking the required box, then simulate the requests. The service will compile statistics on how well it covers both incoming and outgoing messages. It will examine the contents of requests and responses to determine which XML elements and attributes are utilised (SOAP passes data in the XML format). The bodies of requests and responses may contain intricate data structures with numerous parts at each level. Aspects on all levels will be checked by the service.
Coverage Results
A tree-like structure of the operations specified in your specs and a tree-like structure of the virtual operations in your service are both displayed on the Coverage page:
Virtual Operation Results
Expand the bar corresponding to your virtual service to see coverage results for virtual operations.
There are child nodes for each operation node that relate to a certain message pair (request-response). The page utilises red for areas that are uncovered and green for areas that are covered.
A parent element is considered to be covered if at least one of its children is. The percentage of covered items is also shown on the page.
The sum of each child value at each parent node in the tree determines the number of parent nodes.
Select the request or response in the tree, then go to the Message Coverage page on the right to discover what area of the WSDL definition it addresses. Hide the editor you could have launched to the right of the ReadyAPI panel if the page caption is not displayed.
Select the request or response you want to see the contents of in the tree, then go to the Message Content tab on the right.
WSDL Coverage Results
The summary coverage results for the messages defined in your WSDL are displayed in the tree nodes under your WSDL spec node.
Request, Response, and Fault are the two or three child nodes that each message node has (if defined in WSDL). Each node's output is a merger of your virtual service's coverage outcomes of the simulated virtual operations.
Select this request or response bar in the tree (or select its child Body node) and navigate to the Message Coverage page on the right to see the precise area of your WSDL that it covers.
Coverage Options
You have a variety of options using ReadyAPI to modify the coverage procedure. Click on the toolbar to see or edit them. You can specify how ReadyAPI should handle empty elements or elements with question mark placeholders, which elements it should skip during the check, and how it should calculate coverage using the element values in the succeeding dialogue box.
More Coverage Results
Results of the coverage check for the full virtual service are shown on the coverage page. On the other pages of your virtual service editor, you can view the outcomes of the coverage for requests and responses.
Setup Page
The following steps are used to view the convergence result from setup page:
Select the desired response on the Setup page of the virtual service editor. The response editor will appear as a result on the right.
Select the Coverage > Enable Message Coverage check box in the editor on the right.
You can observe in the response data what parts of the WSDL response definition are covered (green denotes covered elements, red denotes uncovered items).
You don't need to run the service or choose the Enable Coverage check box on the Coverage page of the virtual service editor in order to run this check.
Transaction log
You may quickly determine which section of the WSDL standard the simulated requests and responses addressed by looking at the Transaction Log. Follow the steps:
Choose a request or answer from the Transaction Log page. The request or answer log will then open to the right.
Select the Coverage > Enable Message Coverage check box in the log on the right.
You do not need to check the Enable Coverage box on the Coverage page of the virtual service editor in order to examine this data.
Frequently Asked Questions
What are the three behaviour settings that are used by JMS virtual services?
The three behavior settings used by JMS virtual services are latency, Response Delay, and Max Threads.
What is the use of the error body settings?
The error body specifies the error response's body contents.
What does the Error Code contain?
The Error Code contains the simulated error's HTTP response code.
Conclusion
In this article, we have extensively discussed the details of Settings in Ready API along with the details of Authentication, Behavior Settings, and Coverage Settings in Ready API.
117+ registered 