Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.
Testing an SOA project - 5 tips ...
Options
LegacyForum
Posts: 1,664 ✭✭
The lynchpin of testing web services is the WSDL file. That is the ‘Web Service Definition Language’ file that details the operations available as a web service.
Before getting into the usual functional testing it would be wise to set up tests for the following aspects of the WSDL file.
1/ Being written in XML, it has a schema definition file associated with it. Check that the WSDL complies with the schema definition.
2/ The WSDL may also refer to external resources via URLs. Check that all these URLs are valid, and can be connected to.
3/ The concept of web services is that they may be used by other as yet unknown clients. To assist with this, services should comply to WSI Interoperability standards. Check for compliance to these, and document any discrepancies, even if they are accepted by the project as being ' as designed'.
4/ It may also be useful to set up a regression test for the WSDL file itself, just so you know if it gets changed. A changed WSDL file could mean that some of your functional tests get invalidated.
5/ The above are all pretty 'noddy' tasks when you have the right tools. In fact just give SOAtest a WSDL file, and it will generate tests for all of them, just 'check' the 'Create WSDL Tests' box when creating a project.
Before getting into the usual functional testing it would be wise to set up tests for the following aspects of the WSDL file.
1/ Being written in XML, it has a schema definition file associated with it. Check that the WSDL complies with the schema definition.
2/ The WSDL may also refer to external resources via URLs. Check that all these URLs are valid, and can be connected to.
3/ The concept of web services is that they may be used by other as yet unknown clients. To assist with this, services should comply to WSI Interoperability standards. Check for compliance to these, and document any discrepancies, even if they are accepted by the project as being ' as designed'.
4/ It may also be useful to set up a regression test for the WSDL file itself, just so you know if it gets changed. A changed WSDL file could mean that some of your functional tests get invalidated.
5/ The above are all pretty 'noddy' tasks when you have the right tools. In fact just give SOAtest a WSDL file, and it will generate tests for all of them, just 'check' the 'Create WSDL Tests' box when creating a project.
0