Change of Style Architecute :- SOAP to REST
I had a query that actually takes in to account change in implementation of Web Services using style architecture.
In our current project , the Web Services are implemented using SOAP style architecture. But it may be the case in future when the style of architecture can be shifted to REST based style of architecture.
SOATest gives the feature to handle both type of style architectures.
But my concern is if say the style changes from SOAP to REST , then does SOATest gives the feature to shift from one platform (SOAP) to other (REST).?
Can someone also throwlight on how much rework and maintenance would be needed to handle above situation using SOATest tool only.
Thanks once again. Looking forward for reply.
Cheers
Gyan
Comments
-
Hi Gyan,
I think the answer is mostly dependent on your environment, for example what parts of the message that the SOAP client was sending are changing? Is your payload changing from SOAP based XML to regular plain old xml? Whenever you do big architectural changes like this, I think its a given that you will have to do some re-work on your test cases.
There are a great deal of best practices that Parasoft recommends that you follow which can greatly simplify the process of having to make changes/do re-work on your test cases. You can find these best practice recommendations by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide >Best Practices Guide. Some of these may include:
1) Global Tools/Properties: for cases when you find yourself reusing a tool with specific values often, you can create a global tool and use that throughout your tests, that way when you change the global tool it propagates to all of the instances of that tool, making re-work a snap. More info by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide > Functional/Integration Testing > End-to-End Test Scenarios > Adding Global Test Suite Properties
2) Reusable Modules: In a similar vain as above, you can create a .tst file which is referenced in other .tst files, and when you change the referenced .tst file that change propagates to all of your test cases which reference that .tst file, making re-work easier. More info by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide > Functional/Integration Testing > End-to-End Test Scenarios > Reusing/Modularizing Test Suites
3) Of course SOAtest has a great deal of cut/copy/paste functionality, for example you can copy the xml in Form XML view of you SOAP client, and paste that into the Form XML of your REST client, etc. If you are maximizing the amount of things that your test cases can re-use, than changing clients should not take as much re-work.
SOAtest actually has 2 tools which can test RESTful services, both the REST Client and the Messaging client, depending on your needs. Are you looking to still use xml as your payload? Would you want to utilize the Form Input view which is a schema aware view? The messaging client has this view, so if you had a schema associated with the xml payload than perhaps using the Messaging Client would be optimal for testing your RESTful services. If you wanted to utilize the flexibility that REST client provides with choosing http methods and constructing and parameterizing the request URL, than perhaps the REST client is the best choice for you? More info by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide > Functional/Integration Testing > SOA Functional Tests >Testing RESTful Services.
Regards,
Jon0 -
Hey Jon,
Thanks a ton Jon .
Yes some of the points u mentioned , we too have designed on the same lines.
I will def work upon the hints and directions you have provided and then will be in more better position to pitch in my queries.
Thanks once again Jon
Cheers
GyanHi Gyan,
I think the answer is mostly dependent on your environment, for example what parts of the message that the SOAP client was sending are changing? Is your payload changing from SOAP based XML to regular plain old xml? Whenever you do big architectural changes like this, I think its a given that you will have to do some re-work on your test cases.
There are a great deal of best practices that Parasoft recommends that you follow which can greatly simplify the process of having to make changes/do re-work on your test cases. You can find these best practice recommendations by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide >Best Practices Guide. Some of these may include:
1) Global Tools/Properties: for cases when you find yourself reusing a tool with specific values often, you can create a global tool and use that throughout your tests, that way when you change the global tool it propagates to all of the instances of that tool, making re-work a snap. More info by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide > Functional/Integration Testing > End-to-End Test Scenarios > Adding Global Test Suite Properties
2) Reusable Modules: In a similar vain as above, you can create a .tst file which is referenced in other .tst files, and when you change the referenced .tst file that change propagates to all of your test cases which reference that .tst file, making re-work easier. More info by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide > Functional/Integration Testing > End-to-End Test Scenarios > Reusing/Modularizing Test Suites
3) Of course SOAtest has a great deal of cut/copy/paste functionality, for example you can copy the xml in Form XML view of you SOAP client, and paste that into the Form XML of your REST client, etc. If you are maximizing the amount of things that your test cases can re-use, than changing clients should not take as much re-work.
SOAtest actually has 2 tools which can test RESTful services, both the REST Client and the Messaging client, depending on your needs. Are you looking to still use xml as your payload? Would you want to utilize the Form Input view which is a schema aware view? The messaging client has this view, so if you had a schema associated with the xml payload than perhaps using the Messaging Client would be optimal for testing your RESTful services. If you wanted to utilize the flexibility that REST client provides with choosing http methods and constructing and parameterizing the request URL, than perhaps the REST client is the best choice for you? More info by clicking Help > Help Contents, then navigating to Parasoft SOAtest User's Guide > Functional/Integration Testing > SOA Functional Tests >Testing RESTful Services.
Regards,
Jon0