Microcks offers mocks but can also be used for Contract testing of API or services being under development. You spend a lot of time describing request/response pairs and matching rules: it would be a shame not to use this sample as test cases once the development is on its way!
From the page displaying basic information on your microservice mocks, you have the ability to launch new tests against different endpoints that may be representing different environment into your development process. Hitting the NEW TEST... button, leads you to the following form where you will be able to specify an target URL for test, as weel as a Runner - a testing strategy for your new launch :
While it is convenient to launch test 'on demand' manually, it may be interesting to consider launching new tests automatically when a new deployment of the application occurs for example... Microcks allows you such automation by offering API for ease of integration. See here for more details.
Different tests runners
As stated above, Microcks offers different strategies for runnning tests on endpoints where our microservice being developped should have been developped. Such strategies are implemented as Test Runners. Here are the default Test Runners available within Microcks:
|Test Runner||API/Service Types||Description|
||REST and SOAP||Simplest test runner that only checks that valid target endpoints are deployed and available: returns a
||SOAP||Extension of HTTP Runner that also checks that the response is syntaxically valid regarding SOAP WebService contract. It realizes a validation of the response payload using XSD schemas associated to service.|
||REST and SOAP||When the microservice mock repository is defined using SoapUI: ensures that assertions put into Test cases are checked valid. Report failures.|
||REST||When the microservice mock repository is defined using Postman: executes test scripts as specified within Postman. Report failures.|
||REST||When the microservice mock repository is defined using Open API: it executes example requests and check that results have the expected Http status and that payload is compliant with JSON / OpenAPI schema specified into OpenAPI specification.|
Getting tests history and details
Tests history for an API/Service is easily accessible from the microservice summary page. Microcks keep history of all the launched tests on an API/Service version. Success and failures are kept in database with unique identifier and test number to allow you to compare cases of success and failures.
Specific test details can be visualized : Microcks also records the request and response pairs exchanged with the tested endpoint so that you'll be able to access payload content as well as header. Failures are tracked and violated assertions messages displayed as shown in the screenshot below :