Wednesday, January 23, 2013

Working with Soap UI - I

Soap UI - The home for functional testing. Do you think it is? Yes, I think it is!!!

I have been working with Soap UI Pro since almost past 1 year. I have never found such a easy tool to test web services. Though I was working on Soap UI since many years, working with Soap UI pro is much easier than working with Soap UI.

I was also surprised to see that for every problem that I faced with Soap UI  I could find some solution within itself. Below mentioned are few examples that I thought to share.
  1. I  have more than 100 test cases in my test suite and when I try to add more test cases to the same suite the Soap UI might hang sometimes.  Unfortunately I have to kill the process and restart it again. Meanwhile all the changes that I made to my project since my last save get lost. I have to redo all the work again.  This happened to me and my team many times. We ended up consoling each other.

 The solution found for this is simple and best feature of AutoSave.



2.  When I execute my entire automated test suite which has around 150 test cases with 10 to 15 test steps in each, most of the times it gets halted with "Out of Memory" error. I again had to kill the process to get rid of it.

The solution found for this issue is to enable "Discard OK Results" option in TestCase Options.



If you have already created your test suite and if it is hard to set this option for each test case the easy way would be creating simple Groovy script and executing it once. Below is the groovy script for enabling this option for all the test cases under your test suite in one go.
//Start of Groovy

testRunner.testCase.testSuite.project.getTestSuiteList().each
{
  it.getTestCaseList().each 
  {
      it.setDiscardOkResults(true)
   } 
}

//End of Groovy

Reference for Improving Testcase Memory Usage: http://www.soapui.org/Working-with-soapUI/improving-memory-usage.html

3. Working with end point URL's. Setting end point URL for all test cases at once can be done by selecting it at Service Endpoints. Double click the Binding under your project and go to Service Endpoints tab and Assign the selected endpoint to All Requests and TestRequests.


If you think you have to work on multiple environments like Test, Staging and Production but don't want to maintain endpoints for each then, the alternative is to define a property for endpoint and call that property in the endpoint url.

Eg: Say your TestServer is soatest1, Staging is soastaging1 and Production is soaprod1 and the endpoint is 

http://soastaging1.com/service/EmployeeInfo

Define a project or test suite property and configure the endpoint to use this property as shown above.

The endpoint url propertised looks like : 
https://${#TestSuite#ServiceEndpoint}/service/EmployeeInfo.

Now just change the values in the property while testing on different servers.

Also ensure that you are using the appropriate protocol to call the endpoint. The Two protocols available are http & https.

http: This is an unencrypted protocol
https: This is an encrypted protocol and is mostly recommended


In my next blog I will be covering the advantages of using the Pro features like DataSoure, DataSource Loop and Data Sink.

Happy Reading!!!