Sunday, 6 November 2016

SoapUI : Get/Set property Value from groovy

Get/Set property Value of a Project from script

To be able to get a property value of a Project  from the mock Service within the same project, you can use the below command under the Script of your mockService
def varProperty = mockResponse.mockOperation.mockService.project.getPropertyValue("someProjectProperty")
And from a groovy script test step you can use
def testCaseProperty = testRunner.testCase.getPropertyValue( "MyProp" )
def testSuiteProperty = testRunner.testCase.testSuite.getPropertyValue( "MyProp" )
def projectProperty = testRunner.testCase.testSuite.project.getPropertyValue( "MyProp" )
def globalProperty = com.eviware.soapui.SoapUI.globalProperties.getPropertyValue( "MyProp" )
To be able to set the same property with a different value using command you can use the below command
mockResponse.mockOperation.mockService.project.setPropertyValue("someProjectProperty", "NewValue")
And from a groovy script test step you can use
testRunner.testCase.setPropertyValue("MyProp", "NewVal")
testRunner.testCase.testSuite.setPropertyValue("MyProp", "NewVal")
testRunner.testCase.testSuite.project.setPropertyValue("MyProp", "NewVal")
com.eviware.soapui.SoapUI.globalProperties.setPropertyValue( "MyProp", someValue )

To get/set values from the assertion script, you can use the below code in your assertion script. This kind of approach may help you with property transfer.
messageExchange.modelItem.testStep.testCase.setPropertyValue("MyProp", "NewVal")
messageExchange.modelItem.testStep.testCase.testSuite.setPropertyValue("MyProp", "NewVal")
messageExchange.modelItem.testStep.testCase.testSuite.project.setPropertyValue("MyProp", "NewVal")

You can repace the hard values with another variable to be able to optimize your code.

SoapUI : Fetching path of the project file

In order to fetch the current path of the project you can use the "projectPath" function of GroovyUtils. This example can be useful when you have to refer files which will be located within project however you do not want to perform modification every time you move them to another location on the same server or another server.
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
def projectDir = groovyUtils.projectPath
def csvFilePath = projectDir + testRunner.testCase.testSuite.getPropertyValue( "externalFile" )
log.info "File : " + csvFilePath

SoapUI : Externalizing target URL and TestSuite custom parameters

SoapUI's best strength is "groovy" which is almost always there to save you from specific project requirements. We had this requirement to externalize target URL of a test step and test suit, and agin groovy was there to save our day.
  • You must accept that you cannot externalize everything, there will always be something that you will have to hardcode. So, we started with hardcoding the path of an external file using TestSuite's custom properties.
  • Add a groovy test step under the test case you want to achieve this functionality.

In case you prefer to update the target URL/end point of the test steps withing TestSuit's setup script then you'll have to modify the script a little bit to be able to fetch the test step name.

Soap Request Schema Validation : mock Services

Below script can be placed under "OnRequest Script" of a mock service to automatically validate the XML Schema compliance to the corresponding incoming request.
The script validates the incoming request and incase the request does not comply to the Schema of the WSDL then an automated fault message is sent by the mock service on behalf of the incoming request. Implementation of this script can help us overcome the situation where we have to manually validate the request sent by application to the mock service to make sure it complies to the schema structure of the WSDL.




SoapUI : Start/Stop of mock services

When you are testing an application which has various interfaces with different application, you will need many mocks to execute your unit tests. With multiple mocks it is also difficult to manage them. Think of a scenario where the application has interface with 20 or perhaps even more application/web services, and in such cases that many number of mock services. In these kind of scenarios starting and stopping all the mocks is a time taking activity. 

So, why shouldn't we automate them :)

Starting mock service

Below groovy script will help you start all the mock services in the current workspace and minimize them all.



Stopping mock service

Below groovy script will stop all the open mock services and close all the open windows under the current soapUI workspace.
 
When your project needs to target to a platform which is accessible only from a proxy, you may have to do it within SoapUI. However, when you are running your project files from a different machine, it might not be feasible to do the same . You can achieve it by putting the below script

SoapUI : set proxy from script

When your project needs to target to a platform which is accessible only from a proxy, you may have to do it within SoapUI. However, when you are running your project files from a different machine, it might not be feasible to do the same . You can achieve it by putting the below script

SoapUI Mocks : Automated response from CSV files

When you have hundreds of responses for an operation within a mockService it can be very difficult to search and modify them. This dificulty increases with the number of people who are working on the same project at the same time trying to edit these responses. Having the responses in an easy editable CSV file is much convinient. To achieve this goal we have found a solution which has been described below : 

Step 1 : Update Mock Service

Update the mockService to validate the incoming request for conformity of the request. You can refer to topic "Soap Request Schema Validation : mock Services" to achieve this level.

Step 2 : Update Operation

Open the operation under mockService and put the script below under 


Here below is full script from the above screen



The above script search for the requested data in the CSV file, if the data is found and value for "returnCode" column is "0" in the CSV file then it returns the "NominalResponse" otherwise returns the response which is mentioned in the place of returnCode under the CSV file. If both these case are failed then it returns "ResponseUnknown". 

Step 3 : Update the Response

The next step is to update the nominal response and parameterize the values with the actual results from the CSV file. Here a new search is made to the CSV file and corresponding data is fetched. Since we already know that the data exist in the CSV file hence no alternate is given, however you are free to improve this script as per your need.



Put the below script (need to udpated for each webservice and each operation) in the "Script" tab of the "NominalResponse". This script fetch the corresponding data from the CSV file and put it in place of the context variables which are used in the response.



The above script has to be made common for all the common responses, if any special case response  is required then add the special case in the CSV file and in the response list and update the scripts according to your needs.