As more and more businesses move to the web, the need for robust and dependable web services also grows. But how can you be sure your web service is up to par? Web Service Testing is essential.
Whether you're a developer building web services for the first time or an experienced tester, this guide lays out an approach to how to test web services. Let’s get started!
Key Takeaways:
- Web services are defined in several ways, but there are two main types – SOAP and REST.
- There are questions you should ask before automating a web service.
- Understanding the basic WSDL is crucial before looking at web service testing responses and requests.
What is a Web Service?
Web Services are defined in many ways.
Web Services are client-server applications or components. Another way to think of them is that web services are methods of communication between two devices over the network. There are two types of web services: SOAP and REST (You'll learn more about them later on)
But how do you test them?
While web services testing can be time-consuming, keeping your site running smoothly is worth the effort.
How to Test a Web Service
I often get asked the question, “How do I go about testing web services?” and the answer I always give may surprise you – the same way you would test any other application!
Generally, the best approach to normal functional testing is the same for web services. But, unlike most other applications, web services don’t have GUI user interfaces.
So take comfort in knowing the functional testing techniques you have always used still apply. Simply think of a web service as a business process without a UI, and write your test case accordingly.
Questions to Ask Before Automating a Web Service
Because web services can be used by many different clients and used in multiple ways, performance testing and negative testing become more critical. I would suggest you make sure there is good test coverage in those areas.
Some good question to ask when automating a web service is:
- Does the service respond with the correct values?
- How quickly does the service send a response to the user?
- Can the service handle expected and unexpected user loads?
- Can the service handle invalid values and exceptions caused by bad data?
What is a Web Service Testing Terminology
The biggest hurdle for most testers is acclimating to the terminology used when talking about web services. For instance:
- WSDLs – an XML format that tells you how to access a web service. A WSDL is automatically generated for you. Most test tools read in a WSDL and present all the information you need to interact with it.
- SOAP (Simple Object Access Protocol) – a protocol that uses XML format to exchange info to and from a Web service.
- SOA (Service-oriented architecture) – a way companies can organize software that can be quickly changed to respond to the marketplace's requirements.
- Web Service – units of software that run in a network. Typically written to handle a specific business process. Web services can be strung together in multiple ways and used by different applications to create desired functionality.
I believe that once the above terms are demystified, the job of testing web services is pretty straightforward. I also feel that the best way to demystify something is to break it down into simple, hands-on examples.
In this series, I hope to present some simple hands-on examples that break down what a web service actually is and how one works in general. Hopefully, knowledge plus know-how will equal automation awesomeness!
What about Rest Services?
REST (Representational State of Transfer) is a lightweight option for developing web services that use the HTTP protocol –a fact that makes it simpler with less overhead than a web service that uses the SOAP protocol.
Most folks have moved from this older method of using a WSDL web service to using REST instead.
For this post, we'll be looking at WSDL-based services, not REST. For advice on how to get started testing REST APIs, check out my post on rest-assured.
How to Create a Web Service
Ok, to get started – let's create our very own web service. We will then use the web service we created as the basis for the rest of this series.
When we start testing and looking at the WSDL and the services request and response, the information should make more sense since we will be able to map the values back to the source where they came from.
Why create a web service?
If you’re anything like me, the best way for you to learn is by actually doing.
I’ve found that to understand how something works, it sometimes helps actually to try it yourself – so I devised a simple example of how to create a web service to help teach some of the concepts of web service testing.
Here’s How to Create a Web Service
Now, we will create a simple service containing one method that combines two numbers. Okay… I admit it’s not the coolest web service, but it will serve our purpose.
- 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, go ahead and copy the following code into notepad:
Basically, the first line s saying that this is a web service and the language used is C#.
- Then we import two namespaces, System and System.Web.Services.
- Next, we create our class DEMOAddNumbers and add our method named AddThis, which accepts two parameters of type integer — x and y. Finally, we add the values together and return an integer value mySum, which contains the sum of the passed parameters.
- Save the file as DEMOAddNumbers.asmx and place it under your wwwroot/WebServices directory. FYI asmx is the file extension used for ASP.NET.
How to Create a web.config File
To get this to work on my machine, I also had to add a web.config file to my C:\Inetpub\wwwroot directory. Open notepad and copy the following:
Name the file web.config and save it under C:\Inetpub\wwwroot
Verify That the Web Service Works
Next, open up your browser and enter the following address:
http://localhost/WebServices/DEMOAddNumbers.asmx/AddThis?x=40&y=2
The page should return the value of 42 (Which, by the way, is also the answer to the meaning of life – hehe)
Sweet – we now have a working web service! In Part 2 of this series, we will use this web service to help answer the question of what is a WSDL?
It's All About the WSDL
We’re now going to take a look at what WSDL is.
A WSDL is an XML document that describes the methods, method parameters, namespace, and handling URL for a web service. WSDLs and other documentation forms are generated automatically whenever a .asmx file receives an HTTP-GET request.
For an example, navigate to:
http://localhost/WebServices/DemoAddNumbers.asmx
This should bring up an HTML page that describes the methods of the DEMOAddNumbers web service along with some other info.
Clicking on the link for the AddThis method from this page will bring up another HTML page that allows you to test the operations of the service.
Pretty cool, huh?!? And now, let’s take a look at the actual WSDL.
Looking at a WSDL
For our web service, enter the following URL into your browser:
http://localhost/Webservice/DEMOAddNumbers.asmx?WSDL
The WSDL for our web service (DEMOAddNumbers) should appear. Notice, once again, that we didn’t do anything special to generate the WSDL — it was created for us automatically.
As you can see, a WSDL document is just an XML document containing information about a web service.
The four main sections of a WSDL
- Element types – These are the data types that are used by web services.
Notice how the WSDL information matches our web services' code.
- Message element – This section describes the messages used by the web service and defines the data elements of an operation:
- Binding element – This describes the communication protocols used by the web service:
- PortType element – The fourth element, portType, is generally considered to be the most important element because it describes the web services and all the operations that can be performed, as well as all the messages of the service
In the section above, the portType element defines DEMOAddNumbersSoap, DEMOAddNumbersHttpGet, and DEMOAddNumbersSoapPost as the name of the ports, and “AddThis” as the name of the operation.
Also, notice that the ports are a Request-Response operation, meaning that our web service can receive a request and will return a response. For example:
Request a request called AddThisHttpGetIn
wsdl:input message=”tns:AddThisHttpGetIn”
Return a response called AddThisHttpGetIn
wsdl:output message=”tns:AddThisHttpGetOut”
Next, let's look at the process of sending and receiving a request from a web service using a test tool.
Web Service Testing Response and Requests
Now that we have a working web service and understand a basic WSDL, let’s take a look at a web service’s request and response.
First, let’s import our WSDL into our test tool of choice. I will be using SOAPUI (a free open-source tool), but you can use whatever tool you like.
In SoapUI, click on ‘File\New soupUI project'. In the New soapUI project, enter the Project Name: AddNums, and for Initial WSDL/WADL enter:
http://localhost/Webservice/DEMOAddNumbers.asmx?WSDL
SoapUI should import the “AddThis” method under 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
Our DEMOAddNumbers web service is the most typical kind in that a requester (in this case, our test tool) sends a request to the service and waits.
The service then processes the request and sends a reply. Let’s see this in action:
For our request, let’s do a positive test by sending the service valid values:
This is the response I got back when I send the request from SOAPUI:
What does SOAP have to do with Web Services
How does this communication take place? Basically, SOAP — which is an XML-based protocol used for communicating with a Web Service — sends info to the request over HTTP. SOAP stands for Simple Object Access Protocol. If we look at our request, we will see soap elements such as SOAP Envelope, Header, and Body.
This is what a typical SOAP XML message contains.
SOAP Faults
For a Negative Test — if we send bad data in the request, a SoapFault should occur. So, if we send. We should get back a soapFault:
As we can see, the SOAP XML is the same as our previous response, but now it also contains a Fault element. A Fault element contains errors and status info.
Open Source API Testing Tools for REST and WSDL-Based Services
Remember, Selenium is just for browser-based testing. You may be wondering which tool to use for Rest and Soap web service-based testing.
Check out my article on 15 Open Source API Testing Tools For REST & SOAP Service. You’ll learn some of the best web service testing tools you can try today!
Testing Web Services Wrap Up
And that’s my take on web services in a nutshell. For a deeper dive, I recommend checking out the site www3school. I’ve also found SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series) to be a great resource book.
If you are using Unified Functional Testing, also check out my latest Pluralsight video course – Quick Guide to API Testing with HP's Unified Functional Testing.
