Forum Discussion

dario_canto's avatar
dario_canto
New Contributor
8 years ago

Refactoring a Request so it change in all its test cases

I have been using the unlisenced version of SoapUI for a couple of weeks, up until I encountered this problem.   I built a project full of REST requests, each of them with a json body with differen...
REST
  • groovyguy's avatar
    groovyguy
    8 years ago

    So, here's an example of what I mean. Some of the SOAP services I test as part of my job can go through what I call "schema churn." Where there is a defect with the WSDL/XSD files that cause new versions to be put out. Sometimes these new WSDL/XSD files are 99.9% the same and only change how an element is define (regex pattern, etc.)

     

    The problem is when these WSDL/XSD files change significantly enough that the actual XML of the requests has new elements or some are no longer present. This means that all of my tests (sometimes hundreds of them) need to change. This is problematic because of what you said. It's tedious and untenable to have to manually update these tests.

     

    I have written a groovy script that can, with the right setup, take a request, or the content thereof, make the necessary changes and save it back to the test step. So let's say I have an old WSDL/XSD set that has the following element:

     

    <element>
      <child1/>
      <child2/>
      <child3/>
</element>

    And all of my tests are based off of that. Let's say the new WSDL/XSD file has:

    <element>
      <child1/>
      <child2/>
      <child3>
            <grandchild1/>
            <grandchild2/>
      </child3>
</element>

    That means all of my tests are now out of date. So I would write a groovy script that steps through every test suite in the project, every test case in each test suite, and each test step in each test case. If the test step needs to be updated (you will need to have the appropriate groovy logic in place for this), you will do :

     

    // Psuedocode

def oldRequest = testStep.getRequestContent();
def newRequest = oldRequest.replaceAll("<child3/>", <child3>\n<grandchild1/>\n<grandchild2>");

testStep.setRequestContent(newRequest);
groovyguy's avatar
groovyguy
Community Hero

Can you make use of Property Expansion? Add a Properties test step and store these values there, and then replace the hard-coded value with ${Properties#PROPERTYNAME}. There's more documentation here: Property Expansion.

dario_canto's avatar
dario_canto
New Contributor
8 years ago

As I said, I am already using Property Expansion (I called it parameters, my bad), but I cannot use property parameters for all these values for the only reason that each request add, or remove, values. And, besides that, my problem right now is with refactoring and maintaining the code, not with defining each test.

 

All tests are done, everything is finished and functional as it is. The problem si that now I realized that, for instance, the T1S1, T2S1 and T2S2 don't need to use the value "startAt", so I planned on deleting them from the JSON, but that would require deleting each instance manually form both those 3 request, and every single use of these requests on my tests. I can do that now for this problem, but I have more changes to do, and this tests are suppose to be useful beyond this week. If I will have to change them all manually on each test case every single time, I'm afraid SoapUI is neither useful for this project, nor for any other project for now on.

 

Sorry for being so pessimistic, I'm a bit frustrated right now.

  • groovyguy's avatar
    groovyguy
    Community Hero
    8 years ago

    I've been where you are and I understand the frustration. I missed the part that you already had a property test step. Another feature you might be able to make use of is digging into accessing the API of ReadyAPI itself. I've used groovy scripts to modify and generate tests on the fly. It takes some work and some understanding, but it allows me to quickly change the form of my requests relatively on the fly.

    • sanj's avatar
      sanj
      Super Contributor
      8 years ago

      Thats the state I am at myself

      I feel I need to use groovy to generate scripts on the fly and that that one simple code change will be required rather than all the test cases.

      the API document can be pretty daunting we need more examples on how to use the API

       

    • dario_canto's avatar
      dario_canto
      New Contributor
      8 years ago

      Thank for the feedback, but I don't understand what do you mean by using scripts :mansad:

       

      I don't want to change the tests dinamically, I'm only talking about changing them during maintenance, or whenever something change in the API. I already have groovy scripts to change values and parameters during test execution.

      • groovyguy's avatar
        groovyguy
        Community Hero
        8 years ago

        So, here's an example of what I mean. Some of the SOAP services I test as part of my job can go through what I call "schema churn." Where there is a defect with the WSDL/XSD files that cause new versions to be put out. Sometimes these new WSDL/XSD files are 99.9% the same and only change how an element is define (regex pattern, etc.)

         

        The problem is when these WSDL/XSD files change significantly enough that the actual XML of the requests has new elements or some are no longer present. This means that all of my tests (sometimes hundreds of them) need to change. This is problematic because of what you said. It's tedious and untenable to have to manually update these tests.

         

        I have written a groovy script that can, with the right setup, take a request, or the content thereof, make the necessary changes and save it back to the test step. So let's say I have an old WSDL/XSD set that has the following element:

         

        <element>
      <child1/>
      <child2/>
      <child3/>
</element>

        And all of my tests are based off of that. Let's say the new WSDL/XSD file has:

        <element>
      <child1/>
      <child2/>
      <child3>
            <grandchild1/>
            <grandchild2/>
      </child3>
</element>

        That means all of my tests are now out of date. So I would write a groovy script that steps through every test suite in the project, every test case in each test suite, and each test step in each test case. If the test step needs to be updated (you will need to have the appropriate groovy logic in place for this), you will do :

         

        // Psuedocode

def oldRequest = testStep.getRequestContent();
def newRequest = oldRequest.replaceAll("<child3/>", <child3>\n<grandchild1/>\n<grandchild2>");

testStep.setRequestContent(newRequest);