As more organisations migrate online, the demand for powerful and trustworthy web services rises. So how can you be certain that your online service is up to scratch? Testing Web Services is critical.
This tutorial sets out a method to testing web services, whether you’re a developer developing web services for the first time or an experienced tester. Let’s get the Blog started!
What is a Web Service?
Web Services are client-server applications or components. Web services may also be thought of as ways of communication between two devices over the network. There are two kinds of online services: SOAP and REST
While web services testing might be time-consuming, it is well worth the effort to keep your site running smoothly.
Here’s How to Create a Web Service
Today we’ll build a small service with only one method that combines two integers.
1. Before you start, make sure you have the following setup:
Microsoft’s Internet Information Services (IIS) is up and running on your machine
The latest.Net Framework SDK is installed
Create a directory under your C:\Inetpub\www.root named WebServices (wwroot image)
- Next, copy and paste the following code into Notepad.:
- Following that, we import two namespaces, System and System. Web.Services.
- Following that, we build our class DEMOAddNumbers and add our function AddThis, which receives two integer inputs — x and y. Lastly, we add the values and return an integer value mySum, which comprises the total of the arguments supplied.
- Put the file in your wwwroot/WebServices directory as DEMOAddNumbers.asmx. In case you’re wondering, the file extension for ASP.NET is asmx.
How to Create a web.config File
Also had to add a web.config file to C:\Inetpub\wwwroot directory to get this to work on the machine. Copy the following into notepad:
You need to name the file as web.config and save it under C:\Inetpub\wwwroot
Verify That the Web Service Works
Next, open your browser and put the following address:
http://localhost/WebServices/DEMOAddNumbers.asmx/AddThis?x=40&y=2
The page should now return the value of 42
All About the WSDL
We’ll now examine what WSDL is and how it works. A WSDL is an XML document that specifies a web service’s methods, method arguments, namespace, and handling URL. When an HTTP-GET request is made to a.asmx file, WSDLs and other document formats are created automatically.
For example, navigate to:
http://localhost/WebServices/DemoAddNumbers.asmx
This should display an HTML page that describes the methods of the DEMOAddNumbers web service as well as some more information.
Clicking on the AddThis method link from this page will take you to another HTML page where you may test the service’s functionality.
let’s take a look at the actual WSDL.
Looking at a WSDL
Enter the following URL into your browser to access our web service:
http://localhost/Webservice/DEMOAddNumbers.asmx?WSDL
Our web service’s WSDL (DEMOAddNumbers) should be shown. Again, we didn’t do anything unique to generate the WSDL; it was generated for us automatically.
As can be seen, a WSDL document is just an XML document that contains information about a web service.
The four main sections of a WSDL
- Element types – These are the data types that web services employ.
Take note of how the WSDL information corresponds to the code of our web services.
- Message element – This section covers the web service’s messages and defines the data parts of an operation
- Binding element – This section defines the web service’s communication protocols:
- PortType element – The fourth element, portType, is widely regarded as the most significant since it specifies the web services and all of the activities that may be done, as well as all of the service messages.
The portType element defines DEMOAddNumbersSoap, DEMOAddNumbersHttpGet, and DEMOAddNumbersSoapPost as the names of the ports, and “AddThis” as the name of the action in the preceding section.
Additionally, the ports are a Request-Response action, which means that our web service may accept a request and respond with a response. For example:
Request a request called AddThisHttpGetIn
wsdl:input message=”tns:AddThisHttpGetIn”
Return a response called AddThisHttpGetIn
wsdl:output message=”tns:AddThisHttpGetOut”
Then, using a test tool, examine the process of submitting and receiving a request from a web service.
Web Service Testing Response and Requests
Let’s look at a web service’s request and response now that we have a functional web service and a simple WSDL.
Then, load the WSDL into your preferred testing tool. SOAPUI will be used.
- Click on ‘File\New soupUI project’ in SoapUI.
- In the New soapUI project, enter the Project Name: AddNums
- For Initial WSDL/WADL enter:
http://localhost/Webservice/DEMOAddNumbers.asmx?WSDL
- SoapUI needs to import the “AddThis” method under the below projects AddNums\DEMOAddNumbersSOAP.
- Double-clicking on the AddThis ‘Request 1’ will show the following:
*Remember — the WSDL should include all the info needed to interact with a web service. That’s why soapUi was able to read in the WSDL and automatically generate a request with the correct inputs for you.
Web Service Request/Response
The most common type of web service is our DEMOAddNumbers, in which a requester submits a request to the service and then waits.
The request is subsequently processed and a response is sent by the service.
What does SOAP have to do with Web Services?
SOAP, an XML-based standard for dealing with Web Services, basically gives information to the request over HTTP. SOAP is an abbreviation for Simple Object Access Protocol. Looking at our request, we can notice soap components like SOAP Envelope, Header, and Body.
This is the content of a typical SOAP XML message.
SOAP Faults
A SoapFault should occur if we send invalid data in the request for a Negative Test. As a result, if we transmit. We should have a soap backFault:
As we can see, the SOAP XML is identical to our prior answer, except it now includes a Fault element. A Fault element contains mistakes as well as status information.
Conclusion
Web Service Testing ensures that all of the Application Programming Interfaces (APIs) offered by your application work as planned. They are comparable to unit tests in that they test particular portions of code as opposed to user interface components.
Web services tests, on the other hand, will often need to be built for each of the available versions of the API so that when a new version of a product is released, you can regression test the newest version of the API as well as all prior versions. This guarantees that legacy clients that are still utilising an older version of the API do not need to make any adjustments.
