Forum Discussion
By the way, below solution given by Smartbear staff also works.
Although not as clean as the one I share in other comment but this also works. If I put all the pieces together what is shared in this post, this is what you have to do (Run tested OK - no changes required below. No addition of property at test case level).
- Create a test case (say with name TestCase1).
- Add a groovy script step (say with name Groovy Script1). Add below code here:
import javax.naming.Context
def list = [1,2,3,"adfadfas"]
context.setProperty("list",list)
log.info "from script 1 " + list
3.Add a second groovy script step (say with name Groovy Script2). Add below code here:
import com.eviware.soapui.support.types.StringToObjectMap
def contextMap = new StringToObjectMap( context )
def list1 = contextMap.list
log.info "from script 2" + list1
4. If you want to add another groovy script step (say with name Groovy Script3). Repeat above code:
import com.eviware.soapui.support.types.StringToObjectMap
def contextMap = new StringToObjectMap( context )
def list1 = contextMap.list
log.info "from script 3" + list1
5. Now add a last groovy script to call the above 3 steps (by running the whole test case). Remember to make this step disabled otherwise while running the test case, this step will again call the test case and you will go in a recurring loop. (So Groovy Script4 (disabled)): add below code.
import com.eviware.soapui.support.types.StringToObjectMap
def contextMap = new StringToObjectMap( context )
def tCase = testRunner.testCase.testSuite.testCases["TestCase 1"]
tCase.run(contextMap, false)
6. Now if you run this disabled step, you will see that the array/list from groovy script1 was passed in all other steps.
note: You can also do the same by adding this run groovy script in another test case and run from there.
Hope this helps!
Cheers, Pramod
- nmrao7 years agoChampion Level 3
Thank you PramodYadav for your efforts and posting the solution.
There is a suggestion:
Change #1
From
import javax.naming.Context def list = [1,2,3,"adfadfas"] context.setProperty("list",list) log.info "from script 1 " + list
To
context.list = [1,2,3,"adfadfas"] log.info "from script 1 : ${context.list}"
Change #2
From
import com.eviware.soapui.support.types.StringToObjectMap def contextMap = new StringToObjectMap( context ) def list1 = contextMap.list log.info "from script 2" + list1
To
log.info "From script 2 : ${context.list}"
But there is a limitation with above approach i.e., that works only if test case is run and does not work if individual steps are run.
Hope you aware of it.
- nmrao7 years agoChampion Level 3Thank you for the comment.
- nmrao7 years agoChampion Level 3
Like it was mentioned earlier, the earlier solution would only work (sharing of object between the groovy scripts) if the test case is run and does not work if individual steps are run.
Here I want to provide an approach which over comes that by using groovy's meta programming.
In script 1, have the below code:
import com.eviware.soapui.impl.wsdl.testcase.WsdlTestCase WsdlTestCase.metaClass.myList = [1,2,3,4,5]
In script 2, have the below code:
log.info "From script 2: ${context.testCase.myList}"
The above even works if individual steps are run.
Hope this is helpful.
Added the above as answer in stackoverflow question
- PramodYadav7 years agoContributor
Hi nmrao , I tried using the metadata approach that you shared to pass lists and use them in stand alone groovy scripts. I am seeing something peculiar. When I assign a list and call it in another script for the "first time", it works fine. But if I make changes in the list and call it again in another script, it still gives me old value. I also tried running from test case level but found the issue to be persisting. Do you know why this behaviour happens? Thanks in advance for your time and help! Below is a sample script and its log results (you can see the last one is after changes and is not as per latest change).
import com.eviware.soapui.impl.wsdl.testcase.WsdlTestCase
def variableval ="adfada"
WsdlTestCase.metaClass.myList1 = ["adfad","my",variableval]
WsdlTestCase.metaClass.myList2 = [1,2,3,4,5,"mdy",variableval]
WsdlTestCase.metaClass.myList3 = [11,2,3,4,5,"mysdfd"]
log.info "From script 1: ${context.testCase.myList1}"
log.info "From script 2: ${context.testCase.myList2}"
log.info "From script 3: ${context.testCase.myList3}"-----------------------------------------------------------------------------------------------------------
- Tue Jun 13 10:36:51 CEST 2017:INFO:From script 1: [adfad, my, adfada]
- Tue Jun 13 10:36:51 CEST 2017:INFO:From script 2: [1, 2, 3, 4, 5, mdy, adfada]
- Tue Jun 13 10:36:51 CEST 2017:INFO:From script 3: [1, 2, 3, 4, 5, my]
- groovyguy7 years agoChampion Level 1
While posting solutions and helping is great, usually reviving a thread that's this old isn't a good idea.
- PramodYadav7 years agoContributor
Well this was a problem that was bothering us for a very long time and we needed a solution badly to make a good solution design. We could also see many other users struggling with the same problem statement without any concrete answers on internet.
Nonetheless, I was not aware reviving a old thread could be a bad idea. Will explore more on this. Any inputs are also welcome and much appreciated on this matter. Thanks!
- groovyguy7 years agoChampion Level 1
Typically in this instance I would start a new thread outlining the problem again and posting a solution. The end-goal of having an answer to the problem is achieved, and it avoids resurrecting a thread over a year old.
The problem with resurrecting a thread that is old is that the people who originated it may no longer visit the forums, and any further contributions may not be noticed especially since people may not necessarily pay full attention to a thread that old.
Related Content
Recent Discussions
- 13 hours agogroovyguy