Unit Testing Framework / WmTestSuite for Testing REST API

, ,
1

Hi,

We’re trying to implement CI/CD using WmTestSuite. We have the following use cases and wondering how can we use TestSuite for those cases.

  1. REST API - Where the service pipeline doesn’t contain any output elements, yet, it sends response using setResponse Method.
  2. Any other integration scenarios as well like TN / etc, which don’t return output pipeline, but, we want to write automated test cases using WmTestSuite.

Please suggest options. Or, if anyone can throw ideas about you’re implementing at other places, it would be great.

Thanks
SS

1 Like
2

Have you considered SoapUI as the test tool for this? IMO it would fit quite well for such test scenarios.

3

Options to verify a Rest Providers (implemented in Integration Server), through WmTestSuite,

Case 1: Provider implementation drops all pipeline and pub.flow:setResponse is used instead as ‘XML data’.

Solution 1: WmTestSuite can invoke a REST provider/resource with “get” or “post” invoke type. It can then, validate the response XML either completely through file compare or through particular XPath.

Solution 2: Use ‘local REST client’, built with “pub.client:http” to invoke the REST resource (under test) and transform response bytes to IS document. Tests, then can be written for this wrapper client.

Example, Wrapper Client service named ‘RestClientXMLData’ is built with services, pub.client:http, pub.string:bytesToString, pub.xml: xmlStringToXMLNode, pub.xml: xmlNodeToDocument, which converts the response to document. Write Test for “RestClientXMLData” Service and pass the URL(of REST provider) and HTTPMethod as input arguments. The response of the client can be validated against pipeline data, just as regular tests.

Case 2: Provider implementation drops all pipeline and pub.flow:setResponse is used instead as ‘Json data’.

Solution 1: Solution #2, mentioned above has to be used here.
Example, Wrapper Client service named ‘RestClientJsonData’ is built with services, pub.client:http, pub.string:bytesToString, pub.json:jsonStringToDocument which converts the response to document. Write Test for “RestClientJsonData” Service and pass the URL(of REST provider) and HTTPMethod as input arguments. The response of the client can be validated against pipeline data as regular tests.

Verify Service Which does not return response Pipeline

WmTestSuite is an Unit Testing tool and expected to test the business logic only, which is written in IS. To override any scenarios where the output is getting dropped, or some async call is made to other endpoints, it is expected to design (empty) mocking during test, so that output is available and core business logic is tested. Could suggest some more exact solutions/reference points had the queried use case here around TN topic is more specific. WmTestSuite, as i know, is already in use for TN related scenarios at customer end.

4

Thanks for the response. Yes, that’s one of the options we explored too. My question was more towards understanding the Unit Testing framework / WmTestSuite functionality.

Thanks
SS

5

Thanks for the detailed message. It’s indeed helpful. In the Solution 2 for Json messages, Is this client service supposed to go to production environment too along with the rest of the business logic?

As well, could you please throw some more light around, the below point:

Thanks
SS

6

#1 The Client service, would be just an helper test utility, which requires to be part of the Test Package, that you would be building for the Test Suites. No changes are required in actual business packages for this test approach.

#2 WmTestSuite has mocking capability which is rather powerful to even to modify the target Service (under test) behavior during test, in order to test it’s logic.
For example, if the Implemented ‘_main’ Service has distinct grouping(i.e. done by different services) for the ‘logic’ (core business processing) and the required ‘action’ (such as setReponse & drop variables, making async calls to other endpoints etc.), then it’s possible to mock/override the ‘action’ to continue getting output from the ‘_main’ service.
With this approach, (theoretically for now), you can test the logic, as part of ‘unit testing’ with the help of WmTestSuite mocking. This was in reference to the following:

If there is any concrete scenarios/use cases around TN /etc. I could try to suggest some specific WmTestSuite usages to test it.

7

Make use of ‘local REST client’, built with “pub.client:http” to invoke the REST resource (under test) and transform response bytes to IS document in automated software testing. You can then write the test for this wrapper client. For instance: Wrapper Client service from the name of ‘RestClientXMLData’ is built with services, pub.client:http, pub.string:bytesToString, pub.xml: xmlStringToXMLNode, pub.xml: xmlNodeToDocument, which converts the response to document. Write Test for “RestClientXMLData” Service and pass the URL(of REST provider) and HTTPMethod as input arguments. You can validate the response of the client against pipeline data, similar to regular tests.
Visit: 404 page - The World’s Leading AI-Led Quality Engineering Company | Qualitest

8

Hi Siva,

The main objective with which the wMTestSuite was created is checking mapping and later it was enhanced to include stubbing and other features. But this cannot be used for end-to-end or Integration testing.

There are tools which are provided by IBM which can be used in this case. (example: IBM Rational Test Workbench)

Regards,
Syed Faraz Ahmed