Test automation approaches for product built in microservice architecture could vary significantly according to the context of testing goals and ways to achieve them. You got an easy life if you are testing a service, that is an isolated entity which is receiving some data and providing a result of it's work in a response, by callback or through additional endpoint. In this case all you need is to cover all the endpoints of the service, and probably figure out how to catch it's callbacks. However, it's not the only case. Sometimes you need to test service which isn't totally isolated, but a part of a chain of interactions. This service could send some data to other services within your infrastructure or even to third parties. This time you got plenty of additional things to be bother of:
how to intercept output data of tested service
how to emulate unavailability or processing errors on the receiving side
how to emulate network issues
Many times I faced this task in practice, and decided to implement a service that could solve main problems in a simple way and at the same time it should be scalable and reusable. So I created "Mockochino", huh.
"Mockochino" has a scalable number of endpoints, handling scenarios for each of them could be setted up in different ways. Handler settings are stored in sqlite, as well as each input request that handlers will receive. Service supports POST\PUT\PATCH requests.
Let's talk about setting up and usage.
In order to create a new endpoint you need to call /settings/init method, as a result, service would generate uuid and create a unique handler with default settings.
{
"uuid": "4356410a-72ba-461b-a935-52b325587b59",
"delay": 0,
"code": 200,
"token": "",
"response": {
"result": true,
"message": "echo"
}
}Details about settings:
uuid - endpoint identifier, for example with the above settings endpoint url would be like http://127.0.0.1:5000/mock/4356410a-72ba-461b-a935-52b325587b59
delay - delay before response in ms
code - response HTTP status code
response - response json object body
token - if not empty, service will verify "Authorization" header in each input request, if token is not equals or it's missing, error will be produced
HTTP status code 401
{
"result": false,
"message": "Authorization failed."
}Endpoint is ready for usage right after handler initialisation. It's ready to catch your requests and emulate any pre-setted scenario. As mentioned before, each input request is stored in db, so there is an option to get them by handler uuid.
Details about methods: