Showing posts with label SoapUI. Show all posts
Showing posts with label SoapUI. Show all posts

Tuesday, October 27, 2009

SoapUI for Data Setup - Use Case

With Soap UI having very useful features, I find this tool helpful for more and more purpose than just testing and coverage. In one of the product implementation, we were trying to setup the initial necessary data (basic and test data) in easy and best way. We needed the initial setup of few organization profiles and users to proceed further in the product implementation. We had three options - 1. Create manually through UI (painful), 2. Create through web service, 3. Write stored procedures (complicated). As second option seemed easy and clean we built the web service requests and ran each of them to setup data. However we felt there was still some more scope for improvement on this. And then flashed the test suite functionality of SoapUI!!

Once I had the idea it was very easy to setup the project on SoapUI with one test case under a test suite. That's it. I created one test step (web service request) for each profile to be created. However user creation required some of the profile information. Property Transfer came in handy to transfer the required values from the response of a specific profile creation request to the user creation request. (I tried many ways to do this with Property Expansion, however couldn't find a way to do this).


The snapshot of the setup is as shown in the figure. As you can see there are multiple SOAP requests, one each for profile/user creation. The property transfer worked fine, however I observed one weird behavior. Though the response xml did not contain any namespace prefix, In Property Transfer I still had to declare the namespace and mention the xpath elements with this namespace prefix. I still need to find a reason for this behavior.

Another notable thing to mention here is to turn on the option to close http connection after every request. Normally SoapUI will open a http connection and sends the web service requests one by one. However due to few unknown problems on data size limit I encountered, the test case was failing at some point midway through the test steps. However after turning on the option to close http connection after every request the data setup ran very smoothly. This option can be accessed under File -> Preferences -> Http Settings.

Tuesday, February 10, 2009

SoapUI - Property Expansion

While profiling one of my web services I was looking for an effective tool for load testing my web service. Initially thought of JMeter, but due to my happy experience with SoapUI in the past I decided to use SoapUI.

My request xml had multiple fields however couple of fields I had to send the same data. This wouldn't have been a problem during unit testing, but while load testing this service the value of these fields should be unique per test request. So my problem was say If I am sending 50 requests then in each request the value of these fields though common should be unique. Example request would be as below...
<soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:web = "http://www.xyz.com/webservices/">
<soapenv:Header/>
<soapenv:Body>
<web:MigrateOrdersRequest>
<web:Header>...</web:Header>
<web:Credentials>...<web:Credentials>
<web:Order>
...
<web:OrderNumber>PO10001</web:OrderNumber>
...
<web:OrderLines>
<web:OrderLine>
...
<web:SerialNumber>PO10001</web:SerialNumber>
...
</web:orderLine>
<web:OrderLine>...</web:OrderLine>
</web:OrderLines>
</web:Order>
<web:MigrateOrdersRequest>
</soapenv:Body>
</soapenv:Envelope>

Here I have to pass both PO number and Serial Number unique and same. I initially looked for groovy script, but didn't work out for me. The other feature which really impressed me was Property Expansion which really did it. The property expansion will evaluate the property for you in the soap request may be it is from implicit objects, properties or any random math expression.

The solution initially looked tough was very very simple in the end. I just created a new TestCase in my soapUI testSuite with just one test step which was the soap request. And I created a load test step in the same test case (visibly load test will have only one test step). I used simple strategy with limit as 5 seconds and Test Delay of 5000 milliseconds and giving as many threads as required to mimic the scenario where 'n' (say 50) test requests hit the server. With other strategies where Test Delay was lesser than limit, the counter was not actually unique as the same thread after Test Delay was creating a new request. The modified request is as below.
<soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:web = "http://www.xyz.com/webservices/">
<soapenv:Header/>
<soapenv:Body>
<web:MigrateOrdersRequest>
<web:Header>...</web:Header>
<web:Credentials>...<web:Credentials>
<web:Order>
...
<web:OrderNumber>PO1000${=context.getProperty("ThreadIndex")}${=context.getProperty("RunCount")}</web:OrderNumber>
...
<web:OrderLines>
<web:OrderLine>
...
<web:SerialNumber>PO1000${=context.getProperty("ThreadIndex")}${=context.getProperty("RunCount")}</web:SerialNumber>
...
</web:orderLine>
<web:OrderLine>...</web:OrderLine>
</web:OrderLines>
</web:Order>
<web:MigrateOrdersRequest>
</soapenv:Body>
</soapenv:Envelope>

Here after every load test the PO1000 needs to be modified to give next set of unique numbers. The catch here is that ${=<expression>}was actually evaluating to a value by soapUI at runtime. This expression can be any expression with the objects available in the context like properties, implicits etc.

Learning programming

    Programming is an interesting world where you apply your skills to build a software program that comes into life when it is run on a com...