Do you think IIT Guwahati certified course can help you in your career?
Introduction
Hey Ninja!!🥷After being involved with ReadyAPI, you must have become familiar with how these tests are designed and structured. We have come to the most crucial part, where we will learn how to work with test steps, their types and implementation. In this blog, you will learn about various types of test steps in ReadyAPI, their functionality and usage. ☀️☀️☀️☀️
Test Steps are the main building blocks of functional testing. Each step runs in sequential order from top to bottom. We can design out test steps by changing their order and behaviour. It is possible to make more complex tests using loops and conditional statements. Let us now go through these steps one by one. ❄️❄️❄️❄️❄️
Sending Requests
There are many test steps related to requests made to an API. We will go through all of them below.
SOAP Request
SOAP extends to the Simple Object Access Protocol. This request sends a request to the testing server, gets a response and verifies with the assertions. We can customise the test step using authorisation, headers and attachments. SOAP Request test steps are connected to the corresponding WSDL operation.
REST Request
REST stands for Representational State Transfer. This test step sends a request (GET, PUT, POST, PATCH, DELETE), get a response and validates it with the assertions. We have to add a REST service to our project to use a REST request. Request test steps are connected to the corresponding REST Service, Resource, and Method in the containing project.
HTTP Request
An HTTP Request is used to call an HTTP service. It is a standalone request which means we can use it to send requests through an HTTP, HTTPS or JMS. You can determine request type, headers, authorisation, and other parameters using this request. We can also define specific assertions for checking the server response.
GraphQL Query
This step comes in handy when we don't have a GraphQL Schema ready and want to test our server against a schema. The GraphQL Query test step is based on GraphQL Query Request. You can add, edit and verify your GraphQL Query test step using the built-in tools of ReadyAPI.
GraphQL Mutation
The GraphQL Mutation test step is based on the GraphQL mutation request. If you don't have a GraphQL schema, use the GraphQL Request test step. You can validate a mutation and response from the server against the GraphQL Request.
GraphQL Request
Use it to send GraphQL Requests without adding GraphQL API to your application. It sends a request that is not connected to the GraphQL Schema. If you already have a GraphQl API, then use query and mutation. You can add, edit and verify your GraphQL Request test step using the built-in tools of ReadyAPI.
API Connection
It is a test step that is used to verify multiple types of APIs. It supports testing from gRPC, Kafka and REST. It publishes and consumes messages from a Kafka broker. We don't recommend it for REST testing. Instead, use the REST Request test step for this purpose.
JDBC Request
JDBC extends to Java Database Connectivity. It sends a database query and returns the response. JDBC connector is required for each type of request you want to send. We can also use it for testing stored procedures from the database. ReadyAPI gives a lot of tools to configure JDBC request testing.
JMS Request
JMS stands for Java Message Service. It uses a SOAP or REST Request test step to send a message to the JMS destination. To create a JMS request, we must have a service added to our project. We can create, edit, verify and log our JMS Request.
XML-RPC
Use this test step to simulate an XML-RPC operation. We can create, edit, verify and log our XML-RPC request. Add XML-RPC service to your ReadyAPI project to use XML-RPC request.
Working with Properties
Properties give us more control over the test steps. We can customize the steps based on properties and make their behaviour more complex and efficient. ReadyAPI gives a lot of flexibility in terms of property management. Let us explore the different property management tools that ReadyAPI has to offer.
Properties
We can define many properties to read and write operations on a file for a test step. It helps to parameterise assertions and requests. The properties at the test step level allow us to:
Read and write data to external files during runtime.
Organise multiple test steps from various test cases.
Property Transfer
We can use this step to transfer data and properties during runtime between test steps or extract it for further processing. Property Transfer allows us to extract information from a response to use it in subsequent requests. This step performs all transfers that we defined at the time of designing the step. Everything happens in the order they appear. ReadyAPI cannot parse XML files that hai Byte Order Mark in them.
Property Wait
Using this step, we can make any step to stop its execution until a property value is fetched from the source. We can use it to check the property values of our projects, virtual services, test suites and other objects. If property matching is successful in the given time, then the step passes; otherwise, it fails.
Data-Driven Testing
A lot of testing also depends on the type of data the project will deal with. Data can be sourced from various locations, and different types of operations can be performed on them. Thus it becomes crucial to test these as well to avoid any leaks and loose ends.
We will now explore different types of testing tools available that work with data-driven testing.
Data Source
It allows us to fetch property values from external sources such as databases, excel files etc. We can use them in our project by populating requests, validating responses etc. Only one data source can be used per test step to configure multiple properties. We can configure the test step automatically, and it will generate values for your request parameters.
Data Sink
We can use it to store property values in various external storage. Saved property values can later be analysed and processed as required. We have multiple data sinks such as excel, file, groovy, JDBC etc. In a usual case, we assign values to the test case properties and then store them to a data sink we need.
Data Source Loop
Data Source Loop runs in support of the Data Source test step to iterate through the available values from the Data Source step. To use it, add the following steps to your test case:
Data Source Step:- It will provide access to the data.
Target Step:- It will perform test actions. It could be one of SOAP, REST or Run Test Step.
Execution Flow
To control the execution flow, various test steps are available in ReadyAPI. Let us go through them one by one.
Conditional GoTo
It works by checking the values in response to the last message and then going to the particular step mentioned in the response. It allows us to define different XPath expression conditions to jump to the specific test step. We must send at least one request to use the Conditional GoTo test step.
Run Test Case
It runs test cases based on conditions specified in the test step. It is similar to calling a function in any programming language. When executing this test step, ReadyAPI runs the called test case and returns to the original test case. We can create modular test cases which run similar tests at the beginning of each test case.
Delay
It stops the execution of ongoing test steps for a pre-defined period. We can specify this time in milliseconds.
Scripting
ReadyAPI gives us several scripting-based testing features. Let us learn about one such part.
Groovy Script
We can use it to run groovy or javascript codes from our tests. Scripting helps us implement complex behaviour for our tests. We have the option to use a script library to extend the functionality of the groovy script.
Validation
ReadyAPI gives us some validation-based testing features. Let us learn about one such part.
Assertion
To verify a service response, use assertions. Assertions are configured within the test step request. It runs as a separate test step, which allows running this step at any place of your actual test. Using assertion, we can assert test properties within a test case or test suite of a project. We can even use boolean logic to implement complex behaviour.
Web Service Virtualization
Web service virtualisation is a process by which we can test our application before it goes into the production environment. This allows us to test complex logic in the development phase only. It saves a lot of time and resources due to early testing. ReadyAPI provides many tools to perform service virtualisation, such as SOAP and REST request virtualisation. We will now go through each one of them.
SOAP VirtResponse
SOAP VirtResponse actively listens to incoming SOAP requests and gives a pre-configured response. It works like a daemon listening for any incoming request. The incoming request is validated as the SOAP request test step response with the same assertions. When the execution encounters a SOAP VirtResponse test step, it temporarily halts execution and waits for the answer to come from the given path and port. After the response is received, testing continues as usual.
REST VirtResponse
It is similar to the SOAP virtual response step, with the difference being that it handles REST requests. Similarly, it returns a pre-configured response for a REST request. It is used for testing asynchronous processes and callbacks. It helps avoid setting up separate virtual APIs to handle incoming requests.
Virtual Service Runner
This test step helps to start or stop a virtual service. It is helpful when you want to test how a service will perform in the absence of other services or a set of services. We need a ReadyAPI Test licence to use this feature which is not available in the free trial.
AMQP
AMQP extends to Advanced Messaging Queuing Protocol. It is an open standard protocol for message passing specially designed for middleware implementation. ReadyAPI has different tools in its belt to manage working with AMQP test step configuration. We will now explore how these steps work.
AMQP Declare Exchange
This test step creates an exchange on the AMQP broker. We need AMQP Support Plugin to use this test step. Also, we need the pro version of ReadyAPI. AMQP broker manages the message passing between applications and projects. Using this step, we declare that we want an exchange, and the broker works it for us.
AMQP Declare Queue
It is similar to AMQP declare exchange, with the change being that we create a queue in this test step instead of exchange. Similar restrictions are also available here. AMQP broker makes a queue for us when we use this step.
AMQP Bind Queue
This step binds a queue with an exchange on the AMQP broker. The exchange then routes different messages to their destination queues. To use this test step, we need the pro version of ReadyAPI and AMQP Support Plugin. We can edit, create and log our AMQP Bind Queue test step.
AMQP Publish
It is used to post a message on the AMQP broker and works similar to how the AMQP publisher works. To use this test step, we need the pro version of ReadyAPI and AMQP Support Plugin. We can edit, create and log our AMQP Publish test step.
AMQP Receive
This test step connects with the AMQP broker and fetches messages from the queue. It simulates the actions of an AMQP consumer.
MQTT
MQTT is a lightweight machine-to-machine network protocol developed by the OASIS organisation. It is designed to handle network connections with remote machines with limited bandwidth. ReadyAPI has tools to manage MQTT testing. Let's explore them one by one.
Receive MQTT Message
This test step simulates the actions of an MQTT client. Using this test step, we can subscribe to a topic on the MQTT broker and get a response/message from the broker. We can edit, connect, configure, authenticate, verify and log our MQTT message test step.
Publish using MQTT
It simulates the actions of an MQTT publisher and connects to the MQTT broker, and sends the message to it.
Drop MQTT Connection
To test scenarios where connections drop unexpectedly, use this test step. It simulates a planned of forced connection drops from the MQTT broker.
Working with Files
API testing involves files from secondary or network storage as well. We need this test step to make our life easier to handle testing in these scenarios. ReadyAPI has several test steps to work around files in API testing.
File Wait
This test step checks if a given file is present on the hard drive or not. It pauses the execution of the test step until the file is found or the period is not over.
Create File
The create file test step makes a file with random contents and can even wait for another function or program to delete it.
FTP
This test step verifies the credentials and uploads files to a specified FTP server. Currently, essential FTP functions are available. Features such as implicit or explicit access or client certificate authorisation are unavailable. It is intended for the passive mode FTP connection.
Miscellaneous
There are a few test steps still left that we are going to cover under this section. These do not fall under any particular category but are still very important.
Manual
This test step is used to make testing interactive or involve humans. Manual tests are skipped when executed through a command line as a pop-up option for the user to select. The manual test step is helpful for:
Startup devices
Manual triggering of buttons to perform specific actions on the website
Check logs or database manually
TestComplete
It runs all the TestComplete tests as part of our ReadyAPI test cases. This step only runs on windows and needs TestComplete or TestExecute.
Send Mail
This test step sends an email as a part of testing. If sending succeeds, then the test passes; otherwise, it fails.
Frequently Asked Questions
What is ReadyAPI?
ReadyAPI is a 'smartbear' product for a one-stop solution for all testing requirements. It provides all the tools required for testing APIs.
What are the test steps?
Test steps are the actual steps that run sequentially to test a given API or service. These are configured and managed using ReadyAPI’s built-in tools.
How SOAP is different from REST?
SOAP is a protocol, whereas REST is an architectural pattern. SOAP uses interfaces to deliver its services, whereas REST uses URLs.
Conclusion
In this blog, you learned about test steps in ReadyAPI. All the important topics related to Test Steps in ReadyAPI were covered in detail.
Also, do refer to other API testing-related articles:
7+ registered 
