Properties in SOAPUI

SOAP is the acronym for Simple Object Access Protocol. There are two versions of SOAPUI: Open Source and Professional. Open Source SOAP UI is freely available which is used to create simple functional tests and Professional is also known as Ready API which is used create and automate advanced API tests. It is lightweight protocol which is used to exchange information in a distributed and decentralized environment. We can perform functional, load, security and compliance testing using SOAPUI. It is simple to use and easily understandable by both technical and non-technical users. SOAP UI is mainly protocol dependent application. The different protocols supported by SOAP UI are SOAP: Simple Object Access Protocol REST: Representational State Transfer WSDL: Web Service Definition Language AMF: Action Message Format HTTP: Hyper Text Transmission Protocol JDBC: Java Database Connectivity JMS: Java Messaging Service HTTPS: Hyper Text transmission protocol Secured SOAP UI can be integrated with other tools like Maven, Hudson, Junit, and Apache-Ant. Some of the important features of SOAP UI are It is used for broadcasting a message It is both language and platform independent It can be used to exchange documents or call remote procedures It is used to perform API functional testing It is used perform non-functional testing like Security testing, load testing and performance testing Allows advanced custom reporting to capture performance parameters in performance testing SOAP UI Properties can be used as variables to store values that can be referred in testing. Normally whenever we send a request, we need to pass input and accordingly we get response, Sometimes in test suite, we will have many requests which needs same kind of input and we need to hardcode the input in multiple places for test execution in every test request. Instead of multiple entries, we can create one property and assign all the input values to that property and we can refer that property value in multiple requests, thereby avoiding hard coding of values and input data duplication. A Property is generally a named string that has a specific value, and we can access via a script or program. Properties provide the extended functionality to store the general information at a central place and then can be accessed at various locations depending on the exposed scope. SoapUI also provides the capability to define and access properties at multiple scopes, which makes the maintenance of tests very easy by allowing them to flow specific characteristics across tests and scopes. If we have some properties that are common to our project level, it can be defined at Project level. Tester can also defined properties at TestSuite level, TestCase level and TestStep level. Properties are a central aspect of more advanced testing with SoapUI. Functional Testing properties are used to parameterize the execution and functionality of tests.

• Properties can be used to hold the endpoints of services, making it easy to change the actual endpoints used during test execution.

• Properties can be used to hold authentication credentials, making it easy to manage these in a central place or an external file.

• Properties can be used to transfer and share session ids during test execution, so multiple test steps or test cases can share the same sessions.

A property can also be considered as a variable in a computer program. If the user wants to define something which can be used somewhere else too, Properties are very useful. Properties can also define dynamically but it is dependent on Groovy script. Let me show how the properties work in SOAP UI with a sample project First login to SOAPI UI WSDL link: https://ws.footballpool.dataaccess.eu/info.wso?WSDL

Import the above WSDL in SOAP UI Go to File> New SOAP Project and enter the WSDL link and name the project as shown below

Click OK button

Let’s take a request with “AllPlayersWithRole”, we need to pass team name and role. This is how the request looks like. If we pass these two input values, we get some response.

We need to create testsuite and testcase based on the above request. Right Click on the WSDL and select Generate TestSuite. Unselect all the requests and select only “AllPlayersWithRole” Request

Click ok button and give the testsuite name as “TestSuite”.

Click ok Button Testsuite is created as shown below

If we clearly observe the above screenshot, we can see that the properties can be created at different levels like Project level(FootBall Info), Suite level(TestSuite) and Teststep(AllPlayersWithRole) level for one request “AllPlayersWithRole”. Let me create a project level property Double click on the project “FootBall Info”, click on properties tab Click “+” button Enter name as “ Message” Value as “This my project level message”

Close the window Now I will create one variable at suite level. Double click on Test suite, go to properties tab and enter the following details: Click “+” button Enter name as “ Message” Value as “This my suite level message”

Close the window Now I will create a property at Testcase level. Double click on Testcase, go to properties tab and enter the following details: Click “+” button Enter name as “ Message” Value as “This my testcase level message”

Close the window Now I will create property at Teststep level. Right click on the Teststep, select Add step and go to Properties

Click ok In properties window, Click “+” button Enter name as “Message” and Value as “This my teststep level message”

Close the window To access the properties, we use Groovy Script. Inside the test step, we need to add Groovy Script as shown below. Right click on the test step >Add Step>Groovy script, Click ok

We have to write Groovy script to access the properties from all levels. The syntax is given below for different levels: Project: ${#Project#PropertyName} TestSuite: ${#TestSuite#PropertyName} TestCase: ${#TestCase#PropertyName} TestStep: ${#TestStepName#PropertyName} Enter the Groovy Script as log.info context.expand('${#Project#Message}') Click Run button Output is displayed as This is my project level message

Similarly if we want access suite level, testcase level property, we need write groovy scripts as shown below and run the script

Then we need to access properties for test step level where we have added a property. We have created a property step in the test step level, hence we need to write Properties name in the syntax: log.info context.expand('${Properties#Message}')

Here we have accessed all the properties from different levels. In the next step, we will see how to use these properties in our requests. Click on AllPlayersWithRole request and enter the Team name as “Argentina” and RoleCode as “D”. Run the request and verify that the country name is Argentina in Response

I will create the property at testcase level and pass the team name and role code properties. Double click on the testcase and click on properties tab and enter the two properties

Now use the properties in our request. Double on the request. Replace the hard coded value with the property names by giving proper syntax: ${#TestCase#teamname} ${#TestCase#rolecode} Run and verify that we get proper response with team name as Argentina

In the above description, I have explained as how we can set and access few properties for our requests in SOAP UI. There are few more properties which are used in SOAP UI Projects:

• ${#MockService#PropertyName} – For MockService property

• ${#Global#PropertyName} – For Global properties, found in File → Preference → Global properties tab. This property can be used across all projects

• ${#System#PropertyName} – For System Property, found in Help → System properties

• ${#Env#PropertyName} – For environment variable

Thank you for reading my blog.