Vladimir Dyuzhev
MockMotor Creator
The Fastest Way to Mock an Existing Service
MockMotor can act as a simple proxy to record and automatically mock the traffic.
Where to Start Mocking an Existing Service?
When you have an existing service that you prefer to mock, you can go the tried and proven route of collecting example requests and responses and adding them to the mock service one by one.
However, with MockMotor, there is a faster way.
Forward to Real Service
When a mock service exhausted all possible mock responses and still didn't find a match to the request, it normally returns HTTP 404.
However, this is not the only option. If a Forward URL is configured for the service, the service makes a call to that URL instead.
When the forward service responds, the mock service copies the response back to the caller.
What's more important, it can record the response as a mock.
How-To
You have a real backend service that you need to mock, and a client for that service (for example, a web front end or a mobile app).
How to record the traffic as mocks?
Step 1. Create a Mock Service with Forwarding URL
In your mock environment, create a new service. Put the URL of the real backend into the Forward URL field.
Make sure that Record Mock trigger is set to No - we just need to test the forwarding before we hit the record.
Step 2. Point your Client Application to Mock Service
Set the URL of the new mock service in the client application's configuration.
In this case, it was http://127.0.0.1:20014.
The client now would call the mock service, and the mock service would forward the request to the real backend. The backend responds, and the mock service passes the response back to the client.
If all is working as expected, the client won't notice a difference.
There is a small, although non-zero chance that this configuration won't work. Some clients and backends do tricky things with the HTTP protocol, expecting particular properties of it, which could be lost or changed due to forwarding. If it is the case, sadly, you have to revert to the manual response entering. Good thing that only a small subset of backends are so picky.
Step 3. Enable Mock Recording
Now turn that mock recording on.
Try the same flow in the client application. The flow should still work, and you should see mocks are created in the mock service.
Note that if through the flow, the client calls the same service multiple times, but with different parameters, the flow may fail this time. This is because the very first call is recorded as a mock and can be used as a response for the consequent calls. If that happens, you have to update the matching conditions for the mock and retry the flow. You may need to do that a few times until the flow passes.
Step 4. Review the Mocks
Navigate to the service's mock responses. You should see one or more recorded mocks.
Here, after I ran a flow that checks the delivery time from Seattle to Houston, I see a single mock response on the list.
For some services, this is enough. Others require some fine-tuning.
Step 5. Fine-Tune the Mocks
The recorded response is too generic. It only matches by the request's first element getTransitTime and doesn't take into
account the actual origin and destination.
To make sure this mock responds only to these particular cities, I add a script that matches the path endpoints:
Step 6. Do a Validation Run
Rerun the same flow. If all is done right, you should see that the client's request is served from the mock.
Future Directions
The fine-tuning of the recorded mock still takes some manual efforts. It would be great if MockMotor was smarter about it, right?
Well, I'm working on that. I'm doing a long-term project that tries to apply the machine learning and AI algos to predict what properties (parameters, elements, headers) within a given request are critical for matching, and which can be ignored.
With any luck, one day, you would have to do nothing but to point your client to the mock service and go have a cup of coffee. MockMotor would do the rest.