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...
  • 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
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.