Automation of web service testing

Introduction

Web services have been around for over a decade, and over the years, there have been many advancements in web service technologies, and many changes to the protocols supported by web services. In the initial stages of web services standardization process, most influential elements of the programming society, such as Microsoft, IBM, SUN, ORACLE, and other similar companies worldwide, agreed on the standard of SOAP. SOAP has been the core technology protocol used for implementing the communication layer between clients and web service containers. Up until few years back, developers have had to make calls to web services by implementing a soap client stub, which was generated using various tools from various vendors. The calls to web services were never standardized, and each company that developed a web service container, implemented it with little variance than other container vendors, and that caused a big headache for developers worldwide, because they had to learn more than one way to call web services. Over the long run, this was unacceptable to the developers’ community, and so companies that develop containers responded to the developers concerns by implemented other standards for calling web services, which made those standards easier to adapt by other container vendors. Some of these standards included support for Restful calling methods, which allowed developers to call a web service method by simply formatting a URL that includes the web service address, method name, and the variable number of arguments that are passed to the method being called. This approach made web services a revived technology. For some time before this new approach was implemented, and because there was no compatibility between different containers using the raw SOAP protocol, developers started giving up on the web service technology all together. When support for Restful calls was introduced, it revived confidence in the web service technology, and the technology quickly took on a new life and companies began using it all over the place. Web services have always been a great concept, and up until now, they were very hard to use. Fortunately, companies like Microsoft and others worked quickly to revamp this awesome technology and made it available to the developers in a much easier to use form. Other features that were introduced in the new world of web services are the ability of a web service to accept more flexible types of data, and also return the same flexible types. These types include the famous JSON and XML formats, in addition to the already existing primitive and complex data types. By supporting XML and JSON data to be automatically converted by the contained to primitive and complex types that a method expected, the developer no longer had to worry about generating client stubs to call web services that supported JSON or XML. The developer can now create a JSON or XML string that resembles the structure of the combination of primitive and complex types that are expected by a method, and the container automatically knows how to serialize these strings into these complex data types. Testing web services Although introducing JSON and XML to the web service technology made it a lot easier for developers to call a web service method, this created more complexity for testers and developers alike to test these web services. In the past, developers were forced to generate a client stub to call a web service, and that stub automatically generated a copy of all the different complex types that were expected by the web service methods. By having these concrete data types available to the client application, creating an instance of these types and populating them with data is very simple in code. The problem is that the developers were the only ones able to test their web services because that could only be done through code. QA teams weren’t able to test web services unless the developer supplied them with an application that had screens to type in the data required for each method, and the application then made the calls to the web services. This solution is fine as long as the developer continuously maintained this application every time he/she changed the web service, or added more methods to it. We all know how time consuming this would be for a developer, having to constantly worry about updating this client UI to work with the latest web service code, and then making sure the latest version is made available to the QA team to be able to properly test his/her latest web service(s). The solution would be to create a generic tool that can automatically discover web services when they are deployed, and automatically generate the forms needed to allow the user to input all the information needed to call the web service method. This is a great idea if it wasn’t so complex to implement. The reason this is so complicated to implement is because of all the different features that modern web services support. The same features that made the web service technology come to life again, made it that much more difficult to automate the testing process. Imagine a tester having to test a web service method that accepts JSON data, and the method requires a complex employee object to be passed in to add a new employee for example. The employee object may include primitive data fields, and it may also contain complex sub-types and arrays of complex sub-types. The employee object may be made up of the employee basic information such as (name, address, social security number, telephone, date of birth, etc.), along with a history of employment, which is represented as an array of EmployeeHistory object. Each EmployeeHistory object contains information about a previous employer, and it may also include other types of complex objects besides the simple type information. You can see where this is going. Now images having to create a JSON string that represents all that information in order to re-create the employee object from the JSON string. This can be a hellish situation for any one that needs to manually test the web service method. The best approach to solve this problem is to create an XML file that can be configured by the developer of the web service, where this xml contains information about each method, the structure of every data type that is expected by a method, and then create the form generation tool to automatically generate forms that are based on these xml specifications. This is not simple, but it is not impossible. As a matter of fact, I was assigned to this exact task by a client, and this is the approach I implemented for them, and that approach worked perfect. The tool I created would read the xml file, and generate the forms required to capture every attribute of every complex object that is part of the parameter list of a method. The end result was a tree view that represented the method parameters, and every node would represent a simple or a complex type. If the node represented a simple type, the user can supply a value at that level. If the node represented a complex type, the user can expand that node, and supply the value of each simple type node under the complex type node. If the complex type node had other complex type child nodes, the same path is followed, which is to continue to expand the complex and child complex nodes until only simple type nodes are present, and the user can then set the value for each of the simple nodes. In the end, this tool collected all this information from the user, and then re-assembled them into a JSON string that represented the entire tree hierarchy. The end result was a string that the web service container can easily serialize to the objects required by the method being called, and voila, everybody is happy. Here are some screenshots of this tool that I developed for the client: