Forum Discussion

LunaLJG's avatar
LunaLJG
Occasional Contributor
5 years ago

SOAPUI Pro (within ReadyAPI 3.2.5) - old project test methods loading POSTs as GETs

We are seeing an odd issue when opening some older SoapUI projects that we haven't run in a year or more.   Many of the REST request test steps that were originally set up as POST methods are loading as GET methods and are pointing to the wrong API end points/resources.  As a result, we are having to edit and fix all the API request links.   What could have caused this to happen?   We see it across multiple projects, but not all.   

 

This is very time consuming to fix so would love to know if this is a known issue and whether there is any other alternative way to fix this faster than manually fixing each test step.

 

(screenshot attached ... sorry for messy text on it).

  • LunaLJG's avatar
    LunaLJG
    5 years ago

    Hi, it is possible we were using the free version when they were created.   Very hard to say.   Is there a way to identify that in one of the files itself?  Or would that be overwritten as soon as we opened it in Pro version in  readyAPI 3.2.5?

     

    I think I will go ahead and close this issue though.   It sounds like this is not something familiar to anyone at this point and no 'known workaround'.   That is what I was trying to find out mainly.  We will remap the methods manually instead.

     

    Thank you.

  • richie's avatar
    richie
    Community Hero
    5 years ago
    Hi LunaLJG,

    Can you comment on the sequence of events of how you noticed this?

    Ehat i mean is, are you saying that this didn't occur with the previous version of ReadyAPI! you had installed (e.g. v3.2.0 for example) and once you opened your workspace in the latest version all of a sudden there appears some corruption in some of the projects?

    Were any of the projects removed from the workspace and were then re-added back into the workspace?

    Considering most POST requests include a payload, if the method has changed to GET, does this mean you've lost all your embedded payloads too, or are you using the Data Drive functionality to source your data?

    Is there any similarity/pattern you can identify across the projects this method/corruption has occurred for?

    Is there any similarity/pattern you can identify across the projects which havent displayed this sort of method/URI corruption?

    Ta

    Rich
    • LunaLJG's avatar
      LunaLJG
      Occasional Contributor
      5 years ago

      My replies are below.   So this sounds like something no one has encountered before as a known issue?  

       

      Can you comment on the sequence of events of how you noticed this?

      Reply:  The projects had note been opened in over a year, maybe 2 years even.  I simply imported it to my workspace and tried to run the tests and they mostly failed.  So as I was looking through them, noticed that the API methods referenced were now wrong.  A colleague of mine has also noticed the same problem.


      Ehat i mean is, are you saying that this didn't occur with the previous version of ReadyAPI! you had installed (e.g. v3.2.0 for example) and once you opened your workspace in the latest version all of a sudden there appears some corruption in some of the projects?

      Reply:  Correct.  These projects were working fine, but it was a year or two ago that they were last run.  So when we opened them in the newer ready API versions and these corruptions came up in a couple of projects  (I'm using 3.2.5... my colleague is on 3.0).  

      Were any of the projects removed from the workspace and were then re-added back into the workspace?

      Reply:   I had never had them in my workspace at all and had never run them before.   So I was loading them up fresh.

      Considering most POST requests include a payload, if the method has changed to GET, does this mean you've lost all your embedded payloads too, or are you using the Data Drive functionality to source your data?
      Reply:   The entire referenced api was also incorrect, not just the fact it switched to GET.  I have to click on the API Request button and repoint it to the proper method.  And it then has the correct details from the method again.  We are not using the data drive functionality.


      Is there any similarity/pattern you can identify across the projects this method/corruption has occurred for?

      Reply:  When I look at the "link to API request" button, I notice that it appears to be always showing the first API method in the list instead of the correct one (screenshot attached).   The endpoint and details look correct in my test step, but clearly the mapping to the API link is corrupted.   

      Is there any similarity/pattern you can identify across the projects which havent displayed this sort of method/URI corruption?

      Reply:  Nothing obvious yet.   I'm trying to look at the xml data itself and compare guids or something that might help me identify the cause.

       

       

    • LunaLJG's avatar
      LunaLJG
      Occasional Contributor
      5 years ago

      Hi, I had typed a long response to your questions and submitted it, but its no longer showing up.  I'm not sure why.  So I guess you are saying that this has not been an issue that was reported before and you've not heard of anything similiar occurring.   

       

      I have noticed that the API button loads up the first API method in the list all the time - as if its lost its connection to the original api.   Any idea how that could happen?  If the root API changed, could that cause this type of behaviour?

       

      I'm using readyapi version 3.2.5 and my colleague has 3.0 and we've both seen the issue.  In my case, I'm newly working on the projects so this occurred when I first loaded them into my workspace.   My colleague has not worked on that project in over a year so likely just loaded it again as well.

      • sonya_m's avatar
        sonya_m
        SmartBear Alumni (Retired)
        5 years ago

        Hi LunaLJG, you reply got into Spam, I've restored it. Please see above.