FAQ

Mockdoor is primarily a mocking and debugging for developers but designed and optimised for large scale, Multi tenanted Microservice environments. What makes Mockdoor unique compared to other mocking systems, and what enables it to scale and be adopted by even large existing systems its its fundamental design. It can act as a normal mock but you can (and it is recommended you do) use it as a middle layer between your services, it transparently proxies requests but learns them while doing so. It can then learn entire systems behaviours for common and repetitive tasks, enabling the ability to train on test data (such as from Automated test runs).

Mockdoor can be run on single tenant and a single or only a few services but its power really shines when put to scale.

Unlike other mocking systems Mockdoors design enables far more than simple mocking. It has also been designed from the start to have minimal setup and configuration to your existing systems and a fundamental believe with Mockdoor is you should never have to change your code to work with Mockdoor and from your softwares perspective it should behave as it Mockdoor isnt even there.

Mockdoor has a huge amount of additional uses that are possible due to its design. Below we will list some examples but stay tuned to our https://www.mymockdoor.com/tutorial-demo-announcements/ for updates and demos on new use cases.

• Setting up “Test” environments: Using groups you can setup your Microservices into a known state for a particular set of tests. For example a “Azure AD customer test environment”. By organising them into groups or using the time travel feature at a group level you can set up all kinds of mocking templates across multiple services with a single click or url change
• Remove dependencies during testing or development: If you have a bunch of Microservices you are currently running in development or on test environments during testing or developing a particular Microservice you can remove this dependency without needing to manually code a mock for all data. Just point the service you are developing to Mockdoor instead, run your tests or development for a while with the real service active, and once you are done, turn off the real service and tell Mockdoor to mock it from now on. Even as changes happen on the dependencies, re-enable them briefly to get the update and you can continue to mock again right away.
• Debugging failed requests: Getting 401s or 403s? or a failed request? With Mockdoor you can view the request history or live feed and check the access tokens or body to see what actually happened. Or if you have a transience error that occurs but is hard to reproduce and its related to the brief state of your services? Run the system with Mockdoor until the error occurs. Enable the Time travel feature (Simulate Time) and your entire environment will replicate the bad state at the time of the error.
• Parallel development of UI and backend (APIs): With Mockdoor running in development environments you can have a hybrid of real and mock data from the same service (Mockdoor). What this enables is UI can use Mockdoor against the real service but when they need to develop an API call and UI for an endpoint that does not yet exist that can easily add this to Mockdoor as a custom mock response without changing any code or configuration at all. When the real service is completed by the API team then just toggle the endpoint to return live results (instead of mock) and it will be running with the real API.
• Multi tenant a single tenant API: Have an API that returns the same response for all tenants but you want to test it on a per tenant basis? Configure it in Mockdoor for each tenant pointing to the single tenant API. Then for the tenants you want custom/different responses override their response.