Refactoring a Request so it change in all its test cases

[dario_canto]

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 different data. After doing this, I build multiple test cases, each of these featuring those request and adding those asserts. But now, after 20 hours of work, I find out that whenever change I make on those requests, doesn't change on the tests cases, which means that I would have to manually modify 30 tests, each of them with 10+ requests.

While researching I found out that the PRO version of the application allows you to do that, and so I got a trial versión to figure out if it does. I created a new proyect, added a new request, defined a json body, and then added a simple test with just that request. No matter the times I change the original request, it doesn't change on the test case. Refactoring ask me for a WADL which I don't have, nor do I plan to have, I just want to change the values of the fields on my json request.

I'll add some examples.

This is my request, it is called T0S0_Basic_Valid, and it send different values, one of them being "origin", which was "SEI", and now I want "BUS". I also added a parameter for the value "client", which was hardcoded, but now I need it to be able to change.

This is my test case. One of the first steps is calling this request, T0S0_Basic_Valid. Now, as you can see, the values didn't change, so now I have to manually change them.

As you can see, I have many similar requests (T1S1, T2S1, etc). Each of them have a similar structure, but they change their inner values, maybe adding new fields on the JSON. I cannot make them all parameters, nor can I constantly change their value inside each test case, as I will requiere to change the request for time to time.

Is there any solution? How can I refactor these requests?

Thank you.

[groovyguy]

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]

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]

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]

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]

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

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 · Accepted solution]

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);

[dario_canto]

Very interesting.

It feels like a bit "overkill" in the sense that I think this shouldn't be necesary to begin with, but I have spent part of the afternoon researching other API Testing tools and none of them seems to implement it(although I'm starting to doubt my researching skills at this point), so I think this is quite helpful.

Thank you very much. I'll implement it.

[groovyguy]

It's not necessary, IF you have a WADL to work with. That can be used with the "Refactor Definition" option on the binding in ReadyAPI. 

For some reason, the WSDL/XSD files I work with do not work with "Refactor Definition" which is why I came up with the groovy script option.