A web service is a unit of managed code that can be remotely invoked using web protocols. This allows you to share your application’s functionality with other programs. Rapise provides native support for testing web services. Web service tests can be integrated with user interface tests for complete coverage.
The purpose of Web Service testing is to verify that all of the Web Service APIs published by your application operate as expected. Web Service API testing requires that you test using all the expected data formats and input parameters.
There are two broad classes of web service:
When you add a web service to your Rapise test project, you get a new REST definition file (.rest) that will store all of your prototyped requests against a specific REST web service. The various REST requests are then created in the REST definition builder:
Rapise’s query builder streamlines the testing of your APIs with robust debugging and message tracing.
Once all the REST operations have been defined and saved as Rapise learned objects, you can call the REST operations from within your Rapise test scripts:
As well as simply calling the DoExecute() method of each REST web service object to call the previously defined operation, you can use the various properties on the REST service object to send through specific parameter values, add/remove headers, change the authenticated user, change the request body as well as inspect all of the attributes in the request and response.
This allows you unparalleled control over the web service request, with the ability to debug and diagnose web service issues in addition to being able to quickly call the learned operations.
Since the REST objects are just like any other Rapise object, you can have hybrid test scripts that call web service methods and also test GUI objects. This is very useful when you want to test how the user interface changes in response to specific web service API interactions, or when you have a user interface that connects to the sever using a web service (for example with a JSON-based AJAX web user interface).
When you add a SOAP web service to your Rapise test project, you get a new SOAP definition file (.soap) that will store all of the test invocations against a specific SOAP web service:
The SOAP test studio works by connecting to the WSDL location that you specify in the Endpoint tab. Rapise will download the WSDL file and display the list of available methods in the SOAP explorer. You can now navigate all the exposed operations and send test requests through to the SOAP endpoint and verify that the results are correct.
You can also click on the Request/Response tab to view the raw SOAP XML that was sent to and from the server. This is very useful when debugging a service that does not work as expected:
To save time, Rapise can generate the test script code automatically for you (instead of having to write it by hand). It does this by recording the operations you have tested and captured the expected results of a successful operation:
When you have finished your testing session, you can click the ‘Create Script’ option and Rapise will generate the appropriate test script automatically, using the saved objects. You can now playback the tests to regression test your API: