Thanks.
Trying to understand. If it is straight forward what are the challenges? It would be helpful to suggest if more information is available or can go over case by case as well when needed.
If the test data used in soap, then the same be useful in Rest as well.
Custom functionality with groovy meaning? What all it does?
There is no fixed and standard solution or ready made tools at hand for this work. Because, each APIs are different, pay loads are different, expected results are different, uses different ways of automation.
Just calculate the amount of time took to automate the existing tests for SOAP functionality. Writing from scratch takes lot of time, resource irrespective of the tool and requires domain knowledge too. At the same, don't think it is simple migration and straight forward or it is seamless migration, lot of factors play the role, and how flexible/agile the existing automation is.
Keep in mind that development of RESTful services took it's own time and new interfaces. To automate this is going to take time.
Migrating the soap tests into REST may be little difficult, takes time, requires good programming skills, but not impossible .
Before that, one needs to analyze and have full understanding of the project structure, artifacts used in it, what is possible to do automatically, what is possible to update with manual intervention and what is not possible (note down them and do later).
What I can think of is:
- Create a project and import the required interfaces/swagger definition. This is manual step. One can do programmatically too. Say, this is a template or target project.
- Create a utility or program which can convert soap request XML to Rest request in Json form. This is the key step.
- If there are many assertions written for xml, two ways of handling it. Depending on the situation, one has to take the decision on how to handle it.
- convert the json response to soap response so that same assertions work. again need to come up with utility which can do the conversion. this is also another critical part of the decision.
- If there is soap response comparison, the above utility can help here too.
- otherwise, come up some utility which can convert the xpaths into json paths for the assertions. And if see there are xquery's used.
- Create another utility or program which can read a ReadyAPI project with soap tests, iterate thru suites, cases. Say, this is source project. And update the target project as going through the tests of source project.
-
- create the same suites, cases in the template project. Same naming conventions are important to avoid breaking of things if those referred in another step(s).
- now in each case, find the type of the step. If soap type, then read the XML from source, convert it to rest json using the above created utility and add it to target project.
- If the soap request step has assertions, they have to created in the target as well.
- If the step type is Conditional go to and using xpath of response then have to come up with alternative approach.
- If the step is of different type than above say groovy or jdbc etc, no need to worry, just add it to the target.
- Of course, if groovy step is reading some soap responses, it has to handled. As mentioned earlier, it plays role if don't convert the json response to soap xml.
There can be lot of factors to look after for this work. That's why I was asking about the details of the project and its artifacts what all things to be considered during the analysis phase of this migration. But you don't seem to pay much attention to respond to questions correctly.
There is one another important aspect is how authentication is done in soap vs rest services. Is there a login service or API or how is it done? This needs to to addressed in a so that all tests can use same token.
One good thing is functionality intact, that is benefit for reusing the existing project to create for RESTful services tests.
Basically, it can be done using Java or Groovy depending on the comfort of the programmer. Of course it requires understanding of ReadyAPI's Java API.
The process may be iterative to get things done in desired manner. So have backup of all the artifacts including the template project.
Overall this is interesting and at the same time challenges as well.
