perfsonar development work

[Michael Michalis <>]

Hi Loukik,

Find my answers in line 

> -----Original Message-----
> From: Loukik Kudarimoti 
> [mailto:]
> Sent: Wednesday, April 25, 2007 1:28 PM
> To: Michael Michalis
> Cc: Loukik Kudarimoti; Ilias Tsompanidis; Jochen Reinwand; perfsonar-
> 
> Subject: Re: soapUI evaluation
> 
> This is a very good analysis of the SOAP UI tool. Very good job Michalis
> and Jochen!
> 
> Keeping in mind the meager manpower that we have to do such testing, it
> is important for us to use tools which reduce the amount of effort
> required for testing and also to use the same tool across all testing
> teams so that they can be re-used later on.
> 
> I have a couple of questions:
> * If for every service we had a well specified wsdl and a more extensive
> rnc which can be converted to xsd which soap ui is happy with (we need
> to investigate what is lacking currently), does the SOAP UI tool then
> considerably reduce the effort required to test a service (compared to
> our current practice?)


Validating the responses is only a part of testing. For my tests a simple
generic validation method was used to check if key elements of the response
were present. So the method was written once and then used with slight
modifications for other requests. So it will not save a great amount of time
but hopefully will give more quality to the tests and a common way to
validate responses.   

> * I am not sure of what level of automation can be achieved. I
> understand that requests and responses need to be either matched using
> xquery or compared against data values using scripts. If this is the
> case, there is preparatory work required to be done for each request. On
> an average how much time does it take to write up a request with SOAP UI?
> 
Requests are created manually. That is you can copy paste an example request
and modify it accordingly, the following requests can be created by copying
and modifying previous requests. So since there is no scripting involved in
creating the request(there can be if one wishes to) requests can be build in
no time. Off course you must first think what do you want to test with each
request and how you will achieve that, and soapUI or any tool can't do
anything to speed up that. But as creating the requests is not the hardest
or most time consuming part of testing. And one can create requests very
quickly by copying and pasting using notepad.
Time can be saved with the use o soapUI when you are parsing the response.
Especially if you are testing services that don't require database access.
In this case checking the result is some XPath expressions and some clicks.
Even if database access is needed, groovy is very powerful in manipulating
xml and accessing mySQL. So in the hands of an experienced user soapUI and
groovy, can save a considerable amount of time. 

To conclude I can give an exact estimate of the time needed to create a
request(meaning by that creating the request and parsing the response)
because it depends on the kind of request and the user familiarity with
soapUI and groovy. But I can say that an experience user will gain a
considerable amount of time comparing with traditional scripting, but an
inexperienced user will have to work hard to understand soapUI and that will
cost him time 
     
> Here is what I can think of as the next steps
> 
> * We need to investigate how to write up wsdls for our service. I
> believe writing up a wsdl is easy for a rpc/encoded style of web
> services but can be a bit tricky for document/literal.
> * We need to investigate why the rncs that we have written are
> insufficient and what can be improved
> * We need to investigate why the xsds generated from the rncs are not
> accepted by the soap UI
Will posting a comment in soapUI's mailing list and discussing the issue
with them, be helpful?
> * Investigate if listing out all the error codes returned by the service
> will be helpful in testing
>

They will be definitely useful.


I hope my answers cleared things up



Michalis