We discussed a set of concepts most associated with web services. Now, it is time to look in to the testing aspects of web services. As we noticed, web services are loosely coupled and autonomous components which are individual units of business logic in SOA. This facilitates a distinguished approach for testing web services. Because of the loosely coupled nature, the services do not maintain tight, cross-service dependencies with each other. Therefore, once a particular web service is implemented, it can be tested independent from others.
This gives the ability to testers to follow a component level testing methodology. Before moving into various integrations, a web service can be tested to verify both functional and non-functional requirements. Once the service is enhanced with different attributes such as security policies, then such a service can also be tested individually to ensure that it functions properly before taking the integration scenarios into account. This gives great flexibility for testers and provides agility to testing processes.
We can identify a set of common approaches for testing web services as follows:
Unit testing
Functional testing of web services
Integration testing of web services
Performance testing
Let's discuss each of these approaches in detail.
A web service is a unit of business logic and it consists of one or more operations. These operations must be tested individually in order to make sure the intended business problems are addressed by web service operations. Therefore, similar to how individual methods in a computer program are tested as units, web service operations must also be unit tested. Unit tests can be developed using the unit test framework associated with the programming language which is used to implement the web services. For example, if web services are written in Java, JUnit framework can be used as the unit testing framework. Generally, it is the responsibility of the author of the web service to write a sufficient number of unit tests to cover the logic of the web service operations.
Once a web service is deployed in a service container, it is subjected to a comprehensive functional verification. The purpose of functional testing of a web service is to ensure that the expected business functionality is given by the web service. There are many approaches to perform functional testing as explained below.
The primary objective of using tools for web service testing is to support the automatic generation and submission of web service requests. As the web service interface is a machine readable XML document, it is not an easy task to read the WSDL and derive tests manually. Therefore, tools can be used to point to the WSDL and generate the corresponding requests automatically, so that the testers can send them to the service with or without alterations. soapUI is a good example of such a testing tool, which can be used in functional testing of web services.
The life for a web service is given by the service container middleware where the service is hosted. Usually, the middleware providers ship the associated client API libraries which can be used to invoke web services programmatically without using any third party tool.
Web services do not essentially run alone. Instead they are integrated with multiple components such as brokers or service coordinators. Once a service is integrated or joined with another component, we should carry out tests to make sure that such integrations do not break the system. For example, in a service-oriented solution, if a service consumer application sends a message to a web service but the message does not conform to the advertised schema of the web service. In this case, the web service usually responds with a SOAP fault. However, if we want to take such a request and transform the request SOAP message such that it is valid according to the schema, then we do not want to ask the consumers of our web service to change the client applications as the service schema is modified. This type of message transformation is achieved by using a broker component, in other words, enterprise service bus (ESB) middleware. According to the transformation rules defined in the enterprise service bus, the request is converted into the correct format and forwarded to the web service. This is a typical example of web service integration. In order to test this type of integration, the request message should be forwarded to the ESB component instead of directly sending it to the web service. Tools such as soapUI can easily be used to send the messages to desired target locations appropriately.
Once we are satisfied with the functional aspects of the web service, it should be tested thoroughly for performance. This includes load and stress testing the web service as well as measuring the performance under various conditions. We can use various open source or commercial tools in web services performance testing. Apache JMeter (found at http://jmeter.apache.org/) is a good example of an open source testing tool which can be used to test web services. The functional tests which we create on soapUI can easily be extended to test the performance of web services. We will discuss the performance testing capabilities of soapUI in detail in Chapter 5, Load and Performance Testing with soapUI.
When compared to traditional testing approaches, there are some unique challenges associated with web services testing.
The autonomous and loosely coupled nature of web services introduces a greater level of scalability and extensibility to the system. All services included in a system are not necessarily built in-house. Some web services can be developed and hosted by third parties. These services can be dynamically discovered and used according to the business requirements. Though this accelerates the delivery of solutions, testing such a system becomes complex because the quality assurance and availability of the third party services are out of your control.
Web services, especially SOAP-based services can use various WS-* specifications. When testing web services which adhere to specifications such as WS-Security, the tester should possess a fair amount of knowledge about the standards and concepts to carry out testing effectively. This introduces a higher learning curve for testers to get started with the testing of web services.
Web services can also be exposed over multiple transport protocols. Thus, testing is not limited to one particular transport such as HTTP. The same web service can be made accessible over transports such as JMS or VFS which requires changes in the testing setup as well as a different set of test scenarios.
In traditional web application testing, test scenarios can be identified quite easily by studying the GUI of the components. As we discussed previously, the operations of web services are exposed to the outside world via machine-readable service contracts (such as WSDLs). Thus, during the early stages of web services development, testers need to use WSDLs as the reference for the derivation of test scenarios which can be difficult as compared to exploring a GUI.
As we proceed with the chapters of this book, we will learn how soapUI addresses some of the aforementioned challenges and make the life of a web services tester easier.
We have discussed the fundamentals of SOA and web services testing. Now, we are ready to explore the world of web services testing with soapUI.