API testing is an integral part of almost every quality analyst in the software industry. There are multiple tools/frameworks available in the market, which aids in API automation. For example, SoapUI is one of the leaders in the market, which has made the API testing very easy for all the testers. It is a cross-platform API or Webservices testing tool that can do both functional and non-functional testing of API or Webservices. Also, as it is java based tool, it can run on most of the latest operating systems, including MAC, Windows & Linux.
Subsequently, in this tutorial, we are going to cover the following topics to start our journey of learning SoapUI:
- What is SoapUI?
- What's a WebService?
- Types of WebService.
- Difference between SOAP and REST.
- What are the various capabilities provided by SoapUI?
- Which SoapUI supports protocols and technology?
- What are the differences between SoapUI vs. SoapUI PRO?
What is SoapUI?
SoapUI is the world’s leading open-source testing tool, which we mainly use for API testing. Some of the well-known facts about SoapUI are:
- It was developed by Eviware in 2005 and later acquired by SmartBear in 2011.
- Additionally, it is a cross-platform desktop-based application that can run of almost all the latest operating systems.
- Apart from functional testing, it can be used for inspecting, invoking, monitoring, simulating, and mocking of APIs and web-services.
- Moreover, it can do various kinds of testings, such as functional testing, security testing, load testing, compliance testing, and surveillance testing of both REST/WADL and SOAP/WSDL-based APIs.
The general architecture of SoapUI projects is as shown below:
Let's discuss all these parts in details:
- Test config files: These are the files that provide configurations related to testing data, expected results, database connection variables, and any other environmental or test specific details.
- Third-party API: These are the third-party APIs that help to create an optimized test automation framework. For example, the JExcel API helps to integrate with Microsoft Excel for creating a data-driven framework.
- Selenium: These are the Selenium JARs that UI automation uses.
- SoapUI Runner: This runs the SoapUI project. Additionally, it is a handy utility for test automation as it allows you to run the test from the command line. Moreover, it acts as a trigger for test automation.
- Groovy: This library enables SoapUI to provide its users with groovy as a scripting language.
- Properties: These are the property files that hold any dynamically generated data.
- Test Report: SoapUI provides a Junit style report. Additionally, it uses Jasper reporting utility for reporting of test results.
Before we jump onto understanding further details of SoapUI and its features, let's first understand what a WebService is and how it is related to SOAP.
What is a WebService?
A web service is a software component that performs a specific task(s) over the web, such as getting data/information, sending or posting data, or updating data. Additionally, a web service exposes a remote service or executable procedure to a client application whose design is platform-independent. Moreover, any client can invoke it irrespective of its programming language. The general communication/consumption mechanism for a web service looks like the below image:
Let's take an example to understand this. Suppose there is a gift shop which is selling products online. The Gift shop technical team has built one part of the application, which holds the inventory of all the products using the .NET tech stack. Additionally, there is a separate application that we use to make the payment, and JAVA builds it. Consequently, the integration between gift shop application and the payment application will be a challenge as their built is on the different technology stack.
Therefore, we can address/solve such an integration issue by exposing an API for integration by the payment gateway team. The inventory application of the Gift shop can consume this API and interact with the payment gateway. However, if this API is deployed on a web server and exposed over the internet, it will act as a web service. Additionally, Web Services can communicate either using XML or JSON protocols, and all the clients can consume them, which supports these protocols.
Let's understand further how a web service works:
How does a web service work?
The Web Service works as a request-response paradigm. In other words, there is an entity that will request for some service to its specific counterpart, namely service provider entity. Upon request, the service provider will respond with a response message. So there are two messages involved here one Request message and one Response message. Consequently, we can depict this communication with the help of the following image:
Several steps have to work right to make a web service call. That is to say, to get a sense of what you would have to do to implement/consume web services in your code, consider the following:
- First, we have to find the web service. It requires that we know the TCP/IP address (or server name) and the port to which we need to connect.
- Secondly, all of the data we want to send must convert into a stream of data (serialized using standard bit formats and character sets).
- Thirdly, we need to format and make a specific request. Similarly, the server needs to send a response.
- Fourthly, all of the data received needs to convert back into objects and variables which our programming environment understands (deserialized).
- Finally, all of this needs to carry out securely!
Types of Web Services :
We can categorize Webservices majorly into two types:
- First, SOAP Web Services.
- Second, Restful Web Services.
Now let's understand both of them in detail:
What is a SOAP Web Service?
SOAP ( Simple Object Access Protocol) is a message protocol that allows communication between distributed elements of an application. Its basis is transferring XML data as SOAP Messages. Additionally, each message has an XML document that holds the data that need to communicate between the client and the server. Moreover, the structure of the XML document follows a specific pattern governed by SOAP. SOAP supports the exchange of XML-coded messages over a transport protocol, such as HTTP and SMTP.
The basic structure of a SOAP message looks as below:
- envelope – It wraps the entire message. Additionally, it contains the header and body.
- header – It is an optional element with additional info such as security or routing.
- body – communicates application-specific data. It's a mandatory element.
- fault(optional) - Provides information about errors that occurred while processing the message.
The SOAP specification has released two versions: SOAP v1.1 and SOAP v1.2. Moreover, irrespective of the SOAP specification version, the message format remains intact.
Representation of a sample message is as below:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="https://www.w3.org/2003/05/soap-envelope" xmlns:m="https://www.toolsqa.com/">
<soap:Header> </soap:Header>
<soap:Body>
<m:GetBooksPrice>
<m:BookName>SoapUIBook</m:BookName>
</m:BookPrice>
</soap:Body>
</soap:Envelope>
This sample SOAP XML depicts different elements and structure of a SOAP message and how they organize in a SOAP message.
What is REST Web Service?
REST stands for Representational State Transfer. In the REST architectural style, data and functionality act as resources, and we can access using Uniform Resource Identifiers (URIs). In addition to this, Restful Web Service is a stateless, client-server architecture which uses HTTP methods to invoke the web services. Moreover, it doesn't specify any specific protocol to use, but in almost all cases, it has preference over HTTP/HTTPS. Few fundamental attributes of a REST Webservice are:
- Resources identification happens through uniform resource identifiers (URIs).
- Additionally, resources manipulate through their representations.
- Moreover, messages are self-descriptive and stateless.
- In addition to the above, multiple representations accept or sent.
- Connectors (client, server, cache, resolver, tunnel) are no related to sessions.
Now when we say REST is stateless, let's understand what exactly is stateless?
A stateless protocol is a protocol in which handling of each particular communication between the client and the server happens as an independent event. Additionally, it is always unrelated to other similar communications. Even though the sending of the multiple requests occurs over the same HTTP connection, the server does not attach any special meaning to their arriving requests over the same socket. Thus, the server does not retain session information or status about each communications partner in a stateless protocol, for the duration of multiple requests.
A simple REST communication looks like below:
In the above image, the client sends an HTTP request to the Webserver. Similarly, the Webserver sends an HTTP response for the same. For communication and needed operation, it can use various methods, as shown below:
Difference between SOAP and REST
Now that we have understood the basic concepts of SOAP and REST let's see some of the significant differences between SOAP and REST.
| SOAP | REST |
|---|---|
| 1. The full form of Soap is the Simple Object Access Protocol. | 1. Rest is Representational State Transfer. |
| 2. It is an XML based message protocol. | 2. It is an architectural style protocol. |
| 3. It uses WSDL for communication between consumers and providers. | 3. XML or JSON send and receive data. |
| 4. Invokes Service by calling the RPC method. | 4. Simply calls via URL path. |
| 5. It does not return the human-readable result. | 5. The result is readable, which is either plain XML or JSON. |
| 6. The transfer is over HTTP, SMTP, or FTP protocol. | 6. The transfer is over HTTP & HTTPS only. |
| 7. Performance is not as good as Rest, because it follows a proper structure. However, it is more secure. | 7. Performance is much better than SOAP- as leaner. Additionally, it is less CPU intensive. |
By now, we should be clear about the concepts of WebServices. Subsequently, let's move to the next section to understand the various capabilities provided by the SoapUI for different types of testing:
What are the various capabilities offered by SoapUI?
The primary goal of the SoapUI team was to provide utility to users for functional and non-functional tests through a single test environment. Based on that vision, it offered various capabilities that suit different kinds of testing. Few of them are:
- Capabilities for Functional Testing: SoapUI offers multiple features that make the functional testing of Webservices very easy. Few of them are:
- Firstly, it supports testing both SOAP and RESTful web services with easy to use GUI.
- Secondly, it allows you to develop data-driven tests and has support for HTTP, HTTPS transport as well as JMS.
- Thirdly, SoapUI Supports web service specifications such as WS-Security, WS-Addressing.
- Fourthly, SoapUI has the capability of multiple environments setup. In other words, it is easy to switch between different environments such as QA, Dev, and Prod Environments.
- Fifthly, SoapUI allows advanced scripting (tester can also develop the custom code depending on the Scenario).
- Lastly, one of the critical features of SoapUI is Command line support, which allows easy integration with CI/CD pipeline. Which, in turn, is a significant ask in a fast pace environment.
- Capabilities for Service mocking: When you are working with distributed teams or consuming third party APIs, we land into multiple situations where the service provider is not yet ready, but the consumer is willing. Therefore, to address such challenges, SoapUI provides the capabilities to mock the dependent services and simulate the web services before their implementation. Consequently, it allows you to test consumer components without waiting for provider implementation.
- Capabilities for Scripting: SoapUI supports Groovy and JavaScript using which we can script the test scenarios.
- Capabilities for Security Testing: SoapUI possesses the capability to perform a complete vulnerability scan. Additionally, it uses the OWASP standards to check for vulnerabilities in the application under test.
- Capabilities for Performance testing: Users can generate performance and load tests quickly using SoapUI. Moreover, it can distribute the Load Tests using multiple Load UI Agents.
Which protocols and technology does SoapUI supports?
SoapUI supports a wide range of protocols and technologies, as shown below:
Where,
- SOAP – Simple Object Access Protocol
- WSDL – Web Service Definition Language
- REST – Representational State Transfer
- HTTP – HyperText Transmission Protocol
- HTTPS – HyperText Transmission Protocol Secured
- AMF – Action Message Format
- JDBC – Java Database Connectivity
- JMS – Java Messaging Service
What are the differences between SoapUI vs. SoapUI PRO?
As we are aware that there are two versions of SoapUI. One being SoapUI (Open source version), while the other one is SoapUI PRO. Let us understand the difference between these two covering across various aspects:
Comparison of Functional Testing features offered by SoapUI and SoapUI Pro:
The following table displays the different features available in open source SoapUI & SoapUI pro.
| Features | SoapUI | SoapUI PRO |
|---|---|---|
| WSDL Coverage | No | Yes |
| Request/Response Coverage | No | Yes |
| Message Assertion | Yes | Yes |
| Test Refactoring | No | Yes |
| Running of Multiple Tests | Yes | Yes |
| Source Driven Tests | No | Yes |
| Scripting Libraries | No | Yes |
| Unit Reporting | No | Yes |
| Manual Test Step | Yes | Yes |
Comparison of Security Testing features offered by SoapUI and SoapUI Pro:
This table helps us understand how SoapUI differs from SoapUI Pro in terms of feature enabling security testing.
| Features | SoapUI | SoapUI PRO |
|---|---|---|
| Boundary Scan | Yes | Yes |
| Invalid Type | Yes | Yes |
| SQL Injection | Yes | Yes |
| XPath Injection | Yes | Yes |
| XML Bomb | Yes | Yes |
| Fuzzing Scan | Yes | Yes |
| Cross-Site Scripting | Yes | Yes |
| Configurable Scans | Yes | Yes |
| Reporting | No | Yes |
Comparison of Load Testing features offered by SoapUI and SoapUI Pro:
The below table helps in identifying the difference between two versions of SoapUI in terms of features enabling load testing:
| Features | SoapUI | SoapUI PRO |
|---|---|---|
| Rapid Load Tests from Functional Tests | Yes | Yes |
| Configurable Load Strategies | Yes | Yes |
| Load Test Assertions | Yes | Yes |
| Real-Time Statistics | Yes | Yes |
| Performance Monitoring | Yes | Yes |
| Statistics Exporting | Yes | Yes |
| Setup/TearDown using Groovy Scripting | Yes | Yes |
| loadUI Integration | Yes | Yes |
| Reporting | No | Yes |
Comparison of reports generated by SoapUI and SoapUI Pro:
| SoapUI | SoapUI PRO | |
|---|---|---|
| JUnit Reports | Yes | Yes |
| Report Data Export | No | Yes |
| WSDL HTML Report | Yes | Yes |
| WSDL Coverage | No | Yes |
| TestSuite Coverage | No | Yes |
| TestCase Coverage | No | Yes |
| Assertion Coverage | No | Yes |
| Message Recording Coverage | No | Yes |
| JUnit Reports | No | Yes |
Key Takeaways
- SoapUI is a platform-independent WebService automation tool that provides capabilities for both functional and non-function automation.
- Additionally, SoapUI supports testing for both SOAP and REST APIs.
- Moreover, SoapUI supports all of the major protocols such as SOAP, REST, JMS, JDBC, WSDL, JSON, and XML, etc.
- In addition to the above, apart from the open-source version, SoapUI provides a licensed version known as SoapUI Pro, which offers extended capabilities for API automation.
To conclude, before deep-diving into the intricacies and usage of SOAP, let's move to the next article, "SoapUI installation and configuration". Subsequently, it will help us to understand how to install the SoapUI on various supported platforms and what all the configurations are available for a user to kickoff the SoapUI journey.
