Debug Execution is a way to troubleshoot your responses if they do not behave in the way you expect them to.
In the Debug Execution mode, MockMotor reports to you all the actions that it takes when it matches the request with the responses and what was the result of those actions was - did the match worked, what was the selected account, what payload was produced and so on. It allows you to quickly spot the point at which the execution did not go as expected, so that you can fix it.
Open Debug UI
On the Response page, click on the Debug button:
A new window will open with the Debug UI.
MockMotor will prepopulate some of the fields for you. You will need to provide the request:
Execute the Request
Now click on Execute:
After a short delay, at the buttom of the page, you’ll see the execution log:
As you can see from the above log, the first response that the MockMotor has tried was GetNearestPostOffice. The response has been matched by the HTTP Method (POST) and that line is coloured green in the log. However, the SOAPAction header required for that response did not match the request SOAPAction, and so that line is coloured red - the request has failed to match the response.
If your request was meant to trigger the GetNearestPostOffice response, you can clearly see now that the issue is the SOAPAction mismatch.
MockMotor then moves on to the next response.
The next response is GetPostOfficeDetail and that one has a matching HTTP Method and SOAPAction. The response is now matched and will be executed.
MockMotor selects an account based on a value from the request (Account Selection line), where it shows you the used expression and the computed value. Even further below, you can see the number of selected accounts and their printout (this can be truncated if too many accounts are selected), the generated payload and so on.
On the left side of the table, there is the overall time since the beginning of the execution and the time that each step took.
These values may help finding responses or expressions that took too a long time to execute. You can then optimize them or move them down the list to remove their effect on other responses.
Rinse and Repeat
You can correct the response in the original window, save it and re-execute the debug to see if there is any improvement - there is no need to re-open the Debug window.