Forum Discussion

AutoBear's avatar
AutoBear
Occasional Contributor
5 months ago

ReadyAPI update REST request body and update test cases

Hi all! I am trying to figure out if there is support in ReadyAPI to update a REST API request body and have the updated parameters being updated in all the test cases in my functional tests where that request is used.

I looked quite a bit into this, both in ReadyAPI itself, online and on this forum, but I cannot find a proper way to make it work as I would like.

Is ReadyAPI currently supporting this use case?

As a workaround for now I am storing the body of my REST API request as a variable and saving it as a custom property on my project. I then invoke that project variable when I need to perform that specific REST API request in my test cases in my functional test.

Why do I want to do this in the first place you might ask? The answer is that I want to be able to have all my test cases updated once there is an update in any of my REST API requests. I don't want to go through all the test cases and update manually each of them.

It seems to be like an obvious feature to have, but I feel like I am either blind and cannot find how to implement it or there is some kind of restriction in ReadyAPI that does not allow to achieve this for some reason.

Looking forward to hearing some feedback from you all, I think and hope I am not the first person with this kind of use case and problem, so I am very curious to see if there is a way to solve it or if I need to accept that it is not possible to handle this in the way I would like.

5 Replies

  • ChrisAdams's avatar
    ChrisAdams
    Champion Level 2

    Hi,

     

    I'm pretty sure there is an "update from WSDL" or "update definitions' like option that ought to then give you the choice whether to all requests.

     

    I've seen it, but I'm not near my machine to be able to be more specific.

  • AutoBear's avatar
    AutoBear
    Occasional Contributor

    Hi ChrisAdams, thank you for the reply! I know it is possible to refactor REST APIs, however in my case I am not updating the actual contract structure of my REST APIs, I am updating the data in the requests. Meaning, for example, that I have a REST API with an array of attributes that can be given as an input and that looks the same contract wise (meaning, I still have a "attributes" array in my request. What is changing is that a new attribute is added. For example I am going from an array with 2 attributes, to an array with 3 attributes (new "attribute3" added).

    Before:

    {
        "container": {
            "attributes": [
                {
                    "code": "attribute1",
                    "value": "123"
                },
                {
                    "code": "attribute2",
                    "value": "456"
                }
            ]
        }
    }


    After:

    {
        "container": {
            "attributes": [
                {
                    "code": "attribute1",
                    "value": "123"
                },
                {
                    "code": "attribute2",
                    "value": "456"
                },
                {
                    "code": "attribute3",
                    "value": "789"
                }
            ]
        }
    }
     
    I hope my case is more clear now with this example and why (I think) I cannot used the ReadyAPI refactoring functionality. Please let me know if I am mistaken! Or if there is any way around it when it come to "bulk update" all the requests that are using a specific API request.
     
    Thanks!
    • richie's avatar
      richie
      Community Hero

      Hey AutoBear 

       

       

      Yeah, no - sorry - Refactor won't cover that off.  having (trying to think of the right phrase here!) - some sort of cascading payload update across all existing test steps would be handy, but I think you're stuck with being able to update the payload template on your API definition (adding in the new object in the attributes array) - then any NEW test steps sourcing the updated API definition would be populated with 3 objects in your array, rather than the previous 2 objects, however - this change wouldn't be reflected with all the test steps that already exist in your project - which is exactly what you are looking for, right? 😉

       

      Sorry AutoBear - ReadyAPI's got a long way to go before it can manage something like that sort of think I reckon!

       

      Cheers,

       

      Rich

  • ChrisAdams's avatar
    ChrisAdams
    Champion Level 2

    Hi,

    I'm not sure about a bulk update to change payload of all requests for a given request.  But it does sound like parameterised requests might be useful to you.  ReadyAPI does this very, very well.  I'd call it a Data-Driven test btu SmartBear speak is (now) functional test.  This is my fave feature of ReadyAPI.

    You can use a file (CSV, Excel) as a datasource.  Iterating over this datasource, you can call any given service API service as many tests with as many different values as you can think of. 

     

    Not quite what you want, but might be of use.... https://support.smartbear.com/readyapi/docs/testing/data-driven/concepts.html

     

  • richie's avatar
    richie
    Community Hero

    Hey AutoBear 

     

    From your description, i think it sounds like you're looking for an "Update API definitions" sort of functionality.  

     

    Have a look at here --> https://support.smartbear.com/readyapi/docs/apis/update/update.html & https://support.smartbear.com/readyapi/docs/apis/update/refactor-rest.html

     

    Have you tried the 'Update Definition' or 'Refactor Definition' options available in the ReadyAPI! menu bar (see attached screenshot)

     

    Do the changes to your APIs result in an updated swagger/OpenAPISpec/wadl being generated by the devs on your project?  As long as you have an API definition like any of the above, you can update your existing APIs

     

    I've used this refactor and update functionality before - although it was a while ago - and it worked well for the most part - however, I'm unsure if this is what you're looking for (I'll come back to why in a sec)

     

    The 'Update' option handles adding new requests to a project and adding new parms to an existing request.

    The 'Refactor' option handles parm, request, request payload content, operation and resource name changes.

     

    ReadyAPI treats the API definitions as almost parents of the associated request test steps. (so like a parent/child relationship).  So if you make a change to the API (i.e. changes to existing request names and existing parm name values and adding new requests, adding new parms), then the associated test step structure in the test cases are updated accordingly.

     

    So - from your description - I think you want to Refactor your API - rather than update it - HOWEVER - I might've missed it - but I'm unsure the level of changes you're hoping to make on a project scale.  If you're adding new parms - then the obviously the values associated with these parms will need to be populated again.  Also - changing the existing parms, I know the parm values were nulled in the test step.  Obviously ReadyAPI doesn't know what you want and can't auto-complete/auto-populate detail it's not aware of - hence why it blanks out certain values.

     

    However - in my case where it blanked out existing values in my test step rather than just pick up what was defined in the API definition, I remember thinking that I was a bit annoyed cos I changed the name of a parm and it blanked out the values in my test step - even though I didn't think it should've.  The parm name changed - it wasn't a new parm - so the value should've persisted - but it didn't.  That was my only complaint but as I say - it was quite a while ago and I'm sure that issue has been resolved by now.

     

    It was like about 3 years ago since I've (had the need) used this functionality, so any quirks probably would've been fixed by now  - i'd still use the functionality again when it comes to it - it really helped, and it meant that for certain changes, I didn't have to go into every single test step in every single test case in every single test suite in my project and update the content - it was done for me!

     

    Does this help at all?

     

    Cheers!

     

    Rich