Through the Test Console, SOAP and REST APIs can be tested and test records can be managed without using any other tool such as Postman or SOAP UI.
The image containing the Test Console is given below:
Test Console consists of 3 parts;
- Request: In this section, request preparation processes are managed.
- Response: In this section, the results of the response are managed.
- Test Records: In this section, you can see the test history and the tests saved as a group.
Creating the Request Address
There are 2 ways to create a request address;
- The endpoint you want to test can be written manually.
- An API Proxy on Apinizer can be tested from the Test Helper interface or a request address can be created via the API definition file.
Generating the Request Address with Test Helper
When the selected button in the image below is clicked, the Test Helper dialog opens.
The image containing the Test Helper settings is given below:
The fields used for the Test Helper configuration are shown in the table below.
The API type to be tested is determined by choosing one of the Proxy, Proxy Group, Swagger, OpenApi, WADL, WSDL options. These types:
These types are selected when you want to test API Proxies in your selected project on Apinizer.
Also, the selected API is tested from the environments where the proxy is deployed.
The parameter list and sample request body of the created endpoint, if any, are also created by Apinizer.
For these types, the request address is created by selecting the enpoint from the URL of the API definition file.
Proxy Group List
|API Proxy groups that can be tested within the same project are listed.|
API Proxies that can be tested within the same project are listed.
The proxy must be deployed to be tested.
|The service URL of the API to be tested. The URL is parsed and the endpoints of the API are created.|
|The endpoint to be tested is selected from among the endpoints available in the API.|
|The environment where the proxy will be tested is selected.|
Adding a Query Parameter
The query parameters of the request are managed from the Parameters tab.
Each edited value is automatically updated on the URL information.
Adding a Header
Request headers are managed from the Headers tab.
Adding a Body
The data to be added to the body of the request can be created in 2 different ways; raw, x-www-form-urlencoded
The assertions tab allows validation with expected values by querying the value in the body with timeout, HTTP status code, body, JsonPath/Xpath regarding the response to be returned when sending the request.
The fields used for the assertions configuration are shown in the table below.
Use Timeout For Assertion
If enabled, the request is authenticated using the timeout value.
Assert Result Status Code
|Activated to verify based on status code.|
Expected Status Code
|The expected satus code value is written.|
Assert Result Body
|Activated to validate the body of the response.|
|The value of the expected response body is written.|
Assert Result XPath
|Activated to validate a value inside the body of the response. The data type of the body value of the response must be in XML format.|
|An XPath query is written for the key information that holds the value to be verified in the response body.|
Expected Xml Result
|The expected result is written in the XPath information to be verified in the response body.|
Assert Result JsonPath
|Activated to validate a value inside the body of the response. The data type of the body value of the response must be in JSON format.|
|A JsonPath query is written for the key information that holds the value to be verified in the response body.|
Expected JsonPath Result
|The expected result is written in the JsonPath information that is wanted to be verified in the response body.|
Timeout and certificate information are managed in the settings tab.
The fields used for the settings configuration are shown in the table below.
|The certificate to be sent in the request is selected or a new one can be added.|
|If a certificate is to be sent in the request, it is activated.|
After the request is sent, it specifies how long it will take to receive a response from where the request is waiting for a response.
Creating a New Test
If a new test is to be performed after the test process is completed, the information of the test areas can be refreshed by clicking the button marked in the image below.
The body of the response is shown in this section.
The headings of the response are shown in this section.
The log of the response information is seen in this section.
The history of each tested request is stored in the Test Console. The history of the test is categorized by the days they were tested.
When the link of the test log is clicked, the request can be retested.
The image containing the test history is given below:
Test History Deletion Procedures
- Click on the Clear All link to delete all history information.
- To delete the day-based history, the relevant day is deleted from the detail menu of the information.
- Deleting only the history is deleted from the detail menu of the relevant history information.
Collection is the creation of test records by structuring them under a group roof so that the tests can be reused.
Each collection can contain more than one collection.
Saving the Test to a Collection
After completing your test, click the marked Save button in the image to save it.
Then, in the dialog named Collection List, click on the link of the collection to which the test will be assigned.
Apinizer creates a collection called 'Default Collection' to start.
After selecting its collection, the test is saved by giving it a name. The default test record is named as the endpoint URL you are testing.
Collection Based Transactions
The operations that can be done on the collection are done through the detail menu of the collection in the image below.
Rename: It is used to change the name of the related collection. The screen that appears when clicked is given a new name and saved.
Add Collection: It is used to add a new collection into the related collection.
Delete Collection: Used to delete the related collection. If a collection is deleted, all records linked to that collection will be deleted.
Registration Based Transactions
Many operations that can be done on the record can be accessed via the detail menu in the image below.
Rename: It is used to change the name of the relevant test. The screen that appears when clicked is given a new name and saved.
Duplicate: It is used to create a copy of the relevant test.
Create Monitor: It is used to create an Uptime Monitor using the related test. Please click to get detailed information.
Delete Test: It is used to delete the related test.
Save As: In order to save a saved test to another collection, the button marked in the image is clicked.