Forum Discussion

TEB's avatar
TEB
Occasional Contributor
7 years ago

REST Request Centralised Management

Hi all

 

First post for me - I have used SoapUI for a while and have an established SoapUI OS test pack operationg with some 40 definitions and 2000+ data driven tests.

 

The service definitions are evolving as new features are added to the software under test - this is fine for the headers etc as these can be managed at the Method level and are inherited at the test step level. Some REST service definitions can be reused many times in test steps and all payloads will contain content that is data-driven. The test cases are usually multiple REST service calls sequenced into a journey.

 

What I am struggling with is managing the XML payloads for the POST and PUT requests. Currently these are managed in the steps themselves and this makes it a pain when a change comes along to, say add a new node to the payload.

 

I have an idea to override the contents of each step from a central location via a Groovy setup script, which I know is possible but I feel may not be the most optimum solution. Is there an easier / more central way of managing these teststep payloads centrally in a similar manner to the headers?

 

Cheers

 

TEB

  • TEB's avatar
    TEB
    Occasional Contributor

    For the groovy-based option I don't want to identify all the steps using a particular service definition method by test-step name to update the payloads - this would lead to a lot of repetition and mean I would need to maintain some sort of map of test steps to service definition.

     

    This leads to a second question for this option - can I get a list of test steps by service method? I am assuming some sort of relationship is stored as the header info can be updated and be inherited by the test steps...

  • TEB's avatar
    TEB
    Occasional Contributor

    Actually, this relationship is clearly visible on the the test step so must be queryable via the api

    • nmrao's avatar
      nmrao
      Champion Level 3

      TEB,

       

      Let me frank by saying not a solution in hand available (at least with me or this response offers any helpful content to you) though this is a very common issue while the new API's being developed. And note sure about Developers how do they deal to test, but for QA/Test engineers, it is really a challenge and time consuming in order to deal with this situation. Once the API's are stable, this won't be requiring, I guess.

       

       

      Let me re-iterate what I understand from the posts.

       

      You want to update the payloads & headers as per the updated definition in the test steps of your project, which has large number of those. Correct?

       

      And looks you already put your think tank a head and talking about map and all.

       

      But for example, there is a method say "add":

       

      1. When the definition is updated, does it not update all test requests?  or at least does not it ask so? Because, it asks so for the case of WSDL / SOAP.

      2. If "add" method is used in n number of test cases, does all the steps have same request (may be I am referring to some optional elements)? If all the requests in test cases needs same request, then job is simple. Otherwise, job is more complex.

      3. Are you using Swagger Definition? or some other format? please specify.

       

      Looks you are using SoapUI Open Source edition and #1 may be obsolete as it won't generate any payload for REST.

       

      By the way, how are you managing to generate payload for each method in your case? This is very interesting and glad to see if it is a generic solution and share if possible.

       

      I did spend some time generating the pay loads automatically for REST in Open Source edition (like how it does for SOAP requests), but that was limited for that specific definition in JSON format with example values, not a generic solution. Had to use some external libraries and implement some listeners. This is where Pro is good generating the payloads automatically and people pay for it. If we want to implement our self, then need lot of programming skills and time to do so, but achievable.

       

       

       

       

      • TEB's avatar
        TEB
        Occasional Contributor

        Hi nmrao

         

        Thanks for the reply, I am mainly interested in identifying the payloads that need to be updated the payloads. I can already overide the request payload but only by identifying the teststep by name. My idea here would be to identify the steps that need to be updated by the method name, then update the payloads either from the example request, an external file or from a groovy script.

         

        In answer to your other questions:

         

        1. yes, I am using SoapUI Opensource, so it doesn't generate the REST Request.

        2. The payloads can vary, but I don't see that as being too much of a problem as this could be handled via Groovy

        3. Not using swagger, but this is something I am looking to introduce - will this add something to distribute the payload to the test steps?

         

        I parked my line of thought over the weekend and then spent an hour or so trying to find through the APIdocs and forum posts how to get a useful value that would tie back to my request definitions. Looks like these values are not so obvious to query on - maybe I am just a bit rusty. When I try and extract from the test step I get null coming back

         

         

        context.getTestRunner().testCase.getTestStepByName("GetShoppingCart").getPropertyValue("Method")

         

         

        I have tried a few speculative names too, like "methodName", "method" etc.

         

        Annoyingly, I can see it on the REST TestCase Properties and I can see it in the xml:

         

         

                <con:config service="OrderService_PostOrderItems" resourcePath="/{Retail Unit}/{Language Code}/retail/bob/customer/{sourceID}/{customerId}/orders/@cart/items" methodName="PostOrderItems" xsi:type="con:RestRequestStep" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

        I found this post - https://community.smartbear.com/t5/SoapUI-Open-Source/change-the-request-type-from-GET-to-POST-using-groovy-in-soap-ui/m-p/149398/highlight/true#M25125 - seemed to provide a way of getting at the property, but haven't had a play yet as I wasn't too sure what the values needed to be for ResourceName, ChildResourceName,  MethodName etc. Maybe those are visible in the xml.

         

        I will have another look later today - if anyone could offer any more advice, that would be most apreciated.

         

        Cheers

         

        TEB