Forum Discussion

rlong98's avatar
rlong98
Contributor
10 years ago

Can you transfer a result value from within a Script Assertion?

I tried every path possible and can't seem to send a result value from within a Scdript Assertion.  Is this possible?

 

Reason I'm doing this is my Script Assertion is performing a division equation.  I don't feel like creating a Groovy Step if I don't have to.

  • rlong98's avatar
    rlong98
    10 years ago

    No - what I was trying to do was after asserting an equation was correct - I wanted to pass the result of the script equation to a property to use later.  I didn't want to rely on transfer, or create another step to for transfer.

     

    So the funny thing was on SoapUI's site they had the solution:

     

    messageExchange.modelItem.testStep.testCase.testSuite.setPropertyValue( "propertyName" , result )

     

    Why It wasn't working for me - (as I shamefully admit) was I was testing this out in a Groovy testStep... (i know duh)...

    When putting it in the script assertion it worked like a charm.

     

    Thank you - I hope to adopt you as a Groovy Friend

  • rupert_anderson's avatar
    rupert_anderson
    Valued Contributor
    10 years ago

    Hi,

     

    Do you mean you want to pass a value/object from a script assertion and use it it some subsequent step?

     

    If so, you can set the value in the context e.g. in the script assertion context["test"]="12345" and then access the value in a subsequent step e.g. using a property expansion ${test} or in a Groovy TestStep e.g. log.info context["test"]

     

    You could also probably get and set global, project, TestSuite, TestCase properties etc via the SoapUI object e.g.

     

    import com.eviware.soapui.SoapUI

    SoapUI.globalProperties.setPropertyValue( "test", "12345" )

     

    and

     

    def firstName = SoapUI.globalProperties.getPropertyValue( "firstName")

     

     

    Hope this helps,

     

    Cheers,

    Rupert

    • rlong98's avatar
      rlong98
      Contributor
      10 years ago

      No - what I was trying to do was after asserting an equation was correct - I wanted to pass the result of the script equation to a property to use later.  I didn't want to rely on transfer, or create another step to for transfer.

       

      So the funny thing was on SoapUI's site they had the solution:

       

      messageExchange.modelItem.testStep.testCase.testSuite.setPropertyValue( "propertyName" , result )

       

      Why It wasn't working for me - (as I shamefully admit) was I was testing this out in a Groovy testStep... (i know duh)...

      When putting it in the script assertion it worked like a charm.

       

      Thank you - I hope to adopt you as a Groovy Friend

      • rupert_anderson's avatar
        rupert_anderson
        Valued Contributor
        10 years ago

        Hi,

         

        Ok, no problem, glad you found out what was wrong :-)

         

        Just as a note, maybe for later, when you want to pass values on to other TestSteps like this and you:

         

        a) want to run your TestCase from a load test or

        b) set a shared property like this from multiple TestCases run concurrently

         

        then it may help you to consider the scope of the object upon which you set your property. So what I mean is:

         

        if you set properties against the (TestCase's) context variable e.g. conext["propertyName"]=result, then there is one copy of this variable per thread or TestCase (safe isolated updates). However if you set a property on a (potentially shared) object like TestSuite (like you have done) in either situation a) or b) then you might find some unusual results as multiple threads/TestCases (sometimes concurrently) update the same property of the shared object! 

         

        Sorry if you already knew this or I didn't put it well enough, but I just wanted to raise it in case it helps you later on i.e. the tip here is that it can be safer (and simpler in terms of syntax) to set properties on the context variable rather than shared objects like TestSuites, Projects etc, even though this works most of the time and lots of people do it.

         

        Would be happy to be your Groovy friend! Groovy is definiately one of the most fun and powerful parts of SoapUI once you become happy with the basics of it! 

         

        Cheers,

        Rupert