when relevant content is
added and updated.
Usually when you think of functional testing, you visualize some sort of User Interface (UI) for inputting data: a well-defined form or page with fields and arrows and boxes and other eye-candy.
And most modern functional test tools were designed around this object-action paradigm.
But what happens in today’s brave new world of Service Oriented Architecture (SOA)? Data inputs still exist, but they are no longer necessarily visual objects, and the web interface to this incomprehensible mechanism is now a mysterious black box called a “Web Service”.
This world was indeed new to me, but my job required that I decide how to incorporate web service testing into an automated functional regression suite. So I spent some time learning what I could about testing in this alien environment — in fact, the learning continues, and I’d like to share my ongoing adventures.
Please forgive any technical blunders: I am definitely a web service neophyte (in all meanings of that word).
I tend to think of programming in terms of analogies, and “service” suggests a restaurant to me (guess I’m hungry).
First, you find a restaurant by its address. Then you go in, sit down, and look at the menu. The menu tells you all the different culinary delights that the restaurant has to offer. You request the entree or meal that suits you, place your order, and the wait-person responds with a meal that is prepared and delivered for your consumption.
Analogously, a web service has an address in the form of a URL. There is a menu written in Web Services Definition Language (WSDL) which describes the items offered by the service, called methods or operations. The order is placed using the XML file format and usually takes the form of a SOAP (which apparently stands for nothing anymore) request (which kind of breaks the restaurant analogy since SOAP should NOT be a part of your meal but bear with me, please). Once this request is submitted, the web service prepares an XML response and delivers it back to the requestor for consumption.
Now, dragging this topic back into the realm of functional testing, the XML SOAP request contains the data inputs for the web service, in much the same way that a form or screen is populated with test data. The XML response contains all the data for an expected response and can be used to determine if a service request test case passes or fails.
That’s the big picture.
In coming installments, we will look at some tools used for testing web services, and processes needed for developing test cases.