Firstly one should have clear understanding of where the properties are going to be used before simply creating them in SOAP UI while developing Test Suites. That is while designing the test cases itself, one should categorize the properties on the basis of whether they are going to be used at the Test Case level or Test Suite level or above.
The primitve way is to simply add a “Properties” Step under any Test Case and load all the required properties in there.
To access such properties in Groovy script:
def props = new java.util.Properties();
props = testRunner.testCase.getTestStepByName(“Properties”);
def propValue = props.getPropertyValue(“PropertyName”);
Explicitly we should load the properties to some object and retrieve the value from there.
If we know that there are some properties which are going to be used at that Test Case level (that is with some/most of the test steps inside that TestCase) then its better to create the Properties at the corresponsding TestCase level. When we double click on any testcase in SOAP UI (2.0.2, and will not mention from now on, till any further update), we see window showing all testSteps under that TestCase, with some tabs below (Description, Properties, Setup Script, Teardown Script). Select the ‘Properties’ tab in there and upload the required properties which shall be used at that Test Case level.
To access these properties in Groovy script:
def propValue = testRunner.testCase.getPropertyValue(“PropertyName”)
This is very simple right, when compared to the previous approach.
In the same way, there might be some properties which could be used across the TestCases, then such properties deserve place in ‘Properties’ tab under the corresponding TestSuite window. Load the required properties there.
To access these properties in Groovy script:
def propValue = testRunner.testCase.testSuite.getPropertyValue(“PropertyName”)
In this way, we can maintain credibility of the code, and Suite becomes more modular.
Comments on: "properties at different levels in SOAP UI" (23)
Hi
I have a test suite with 10 test cases, each test case has between 1 to 5 test steps. All test steps need a session ID that is in the response of the first test step of the first test case.
Is there any way to tell the test suite to do all the steps
1- get session id
2- put session id in test steps
3- run all test steps
automatically, right now I do it manually.
Hi Ehsan,
Initially create a property, say ‘sessionIDProp’, at the TestSuite level.
Just after the first test step (of first TestCase) which yields the sessionID,
place a Groovy step to fetch that sessionID value and set to sessionIDProp
And thereafter, you could simply fetch the sessionIDProp value as needed for the
remaining TestCases using testRunner.testCase.testSuite.getPropertyValue(“sessionIDProp”).
Please get back if more help is needed.
Thanks
Devakara.
GREAT JOB, … but… HOW TO make SAME thing but with setProperty. On diffrent levels (testStep – to – Project)
Hi Corki,
If I understood your question correctly…to set such property (defined at TestSuite level)
in a Groovy Step of any TestCase (of that TestSuite) we need to write
testRunner.testCase.testSuite
.setPropertyValue(”sessionIDProp”,”propValue”)
Hope this helps!
Thanks,
Devakara
Hi,
I am working on some script to parse and find a value in a particular node that comes in the response XML. For example consider the following response XML.
964820537741905915
I want the value in the “token ” tag so that i can pass it on to the next TestStep. Do you know a way to parse this reponse XML and get the value?
I tried using XMLHolder but i am facing two issues.
1. I am not able to get the XMLHolder when i try this as the first two steps of my script. It is prompting me a NULL Pointer exception. What can i do to get a XMLHolder to parse and retrive my value in a particular node?
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context );
log.info( groovyUtils.expand( “projectPath” ));
2. Cannot find any method in XMLHolder that would retrieve me the value in the token tag.
I hope you will help me out.
Thanks.
Hi Abhay,
Could you resend the response xml (for some unknown reason i dont see any xml except for “964820537741905915″)
Cheers,
Devakara.
Using the Xml Holder it can be done.
def respholder = groovyUtils.getXmlHolder(“opName#Response”)
respholder.getNodeValue(xpath_of_param)
Here xpath_of_param is a string containing xpath of the parameter whose value is to be obtained
Hi! Is there a way to not save properties assigned during test run? I don’t want the project file to be modified.
Currently I have to add additional test steps to all test cases to reset properties.
No one wants to answer.
Project save script:
project.setPropertyValue(“aaa”,”set in runtime”)
project.setPropertyValue(“bbb”,”set in runtime”)
project.setPropertyValue(“ccc”,”set in runtime”)
…
What is the best way to pass properties to a test step. I have a groovy script and I intend to invoke a test step (which is a soap request) using testRunner.runTestStepByName. Before doing that I need to set the request properties that are determined at run-time.
I have a step in my test case (part of a test suite) which takes values from a previous step. I have saved off three of those values into properties at the test suite level which my request then references. However, my final parameter for my webservice call is actually a list of IDs (from 1 to N), also obtained from a previous step. Currently I hard-code that list (see below), which doesn’t make my test very dynamic. Is there a way for me to generate this part of my request based on a previous steps response? My only idea so far is to create n properties (id1, id2, id3), etc., and always pass all n properties and use -1 to mean “non-existent”. Of course, I would then have to modify my webservice to ignore -1. Not at all desirable.
Thanks, Tom
snippet from my request xml
${#TestSuite#sourceSystemProperty}
${#TestSuite#activeAgencyIdProperty}
${#TestSuite#activeUserIdProperty}
1584213
988230
Sorry, the xml didn’t paste correctly, but what shows is the three properties I reference from the test suite level, and then beneath that are two IDs. There could be from 1 to N IDs.
Hi,
I have a question on how to set WSS-Password Type dynamically when running my test cases . I am using the below code to set, but it was not getting updated. Can someone please help me out on this
testRunner.testCase.getTestStepByName(“GetDetails”).setPropertyValue(“WSS-Password Type”,com.eviware.soapui.impl.wsdl.WsdlRequest.PW_TYPE_TEXT);
Thanks,
Venkata
When I write Groovy Scriot and try to run, I get an error org.mozilla.javascript.EvaluatorException: Syntax Error.
I get this all the time, where as the same code works fine in my Colleagues SoapUI, what is wrong in my SoapUI. How to resolve this issue.
I’m trying for past 1 week !!!
i have to write groovy script for load test in soapui, is it possible to set property at load test level?
Hi Payal,
We implicitly have Load Test capabilities in SOAPUI – you can right click on any Test Case and say New Load Test; all the test steps of that particular Test case will be now under your new load test.
Hope this helps.
And coming to the property at Load Test level – where exactly you want to use it in your load testing process?
Thanks,
Devakara.
In the load test….
Or maybe in the TestCase…
Anyway here is the answer to the question:
properties to/from loadTest and testStep
http://www.soapui.org/Load-Testing/loadtest-scripting.html
Hi,
I’ve encountered a problem with (non-Pro) SOAPUI, and ran across your post above when researching how to workaround my problem. I’ve been posting about this on Eviware’s forum here:
https://www.eviware.com/forum/viewtopic.php?f=5&t=7953
Basically the problem is that I have a test case with a Groovy script step and a request step. The Groovy script step populates the SOAP request by reading from a file within a set of files. The properties that the Groovy script populates include an “Id” attribute (a unique number for each request) and a “dnstring” element (a user name) in the SOAP request.
I got that working. At this point, the “Id” and “dnstring” properties are at the test case level, and when I create a load test from the test case in SOAPUI, then run to run the load test, it creates multiple threads for running the test case. The problem is that it appears that, in SOAPUI, properties at the test case level “belong” to each individual thread.
In other words, with my properties at the test case level, when I run the load test, and if the load test creates, say, 10 threads, there are 10 completely independent and isolated sets of the properties (one set for each SOAPUI thread).
The main problem/result of this is that the SOAP requests go out with non-unique Ids, because if there are 10 threads, I see 10 different SOAP requests with the same Id.
The reason I found your post above is that I’m thinking that if I put the Id and dnstring property at, say, a higher level in SOAPUI, e.g., maybe at the Test suite or project level, those properties would get “shared” across the threads in the load test.
From your post, and responses to comments, you appear to be very knowledgeable about properties in SOAPU, so I was wondering if you might know if what I’m thinking about (putting the properties at a higher level in SOAPUI) would solve my problem? If so, which level in SOAPUI would work? Test suite, or Project level?
Thanks,
Jim
Hi, thanks in advance for your help, this blog has been pretty helpful so far.
What I’m currently doing is generating multiple values that I’m taking from response headers. I have no problem doing this, and I can easily use a script to store the values in a Properties test step. What I WANT to do is get those values written directly to the Properties section at the Test Suite level, and then in other Test Cases reference the values from the Test Suite level. How do I do this?
Great blog, especially since I’m just beginning with scripting. I am stuck on what seems like an easy thing. I need to run a load test with SOAPUI and generate an output file that shows the thread count at 1-second intervals. I see I can use log.info() to write the message, which I think will already include the timestamp, but I don’t know how to get the running threadcount to drop into the log. Ideally it would be separated from the timestamp with a comma. I will import the file to correlate load with certain application behaviors.
Once we’re writing the log, I’m thinking I could just have a test case that simply writes to the log at one-second intervals, running this simultaneously with the “real” test cases. Would this work?
Thanks in advance -
Edward
Hi devakara,
I am new to groovy scripting language.I want to run the groovy script on soap ui to increase a counter when response time is exceeds from 1 sec.Please do help me how to read the response time while load test is running and increment the counter.
Please note it is TEST SUITE.Awaiting for your reply!!!