How to handle multiple mock response templates while designing a simple Mobile mock API testing system

Question

There's an app that's in iOS, Android and Windows and that has plenty of web services and each web service has different response templates based on the input.

So basically we'd like to run different mock scenarios for testing in mobile app so we can easily catch regression issues and we can use mock system when server is down

So the URLs have absolute and relative URL for example.

https://www.test.com/myapp/getartcollection

So here https://www.test.com is an absolute URL /myapp/getartcollection is a relative URL.

I can change the absolute URL to my own custom web server URL/IP or localhost by using conditional flags while building the URL.

The server system can have one of the web server languages like Java or Ruby or PHP or Dot net etc..

What would be the right place to store the Mock response templates?

1. as a part of mobile app and add a parameter in the request which has the contents of expected response and the requesting URL server language can read the parameter and respond to the client with that.

2. or I can have certain folder structure in server and each folder has related API response templates stored in it so anyone with right permission can FTP it and change the response (JSON or XML) according to the expectation.

3. So what's the best way to keep different response templates organised is it by following different directories as in the URL or can we have everything in one directory and just send the responseTemplateName as header-field in request URL and use the filename to search the response template in one single directory.

Is there any industry standard or recommendations?

Any suggestion related anything to do with this is very welcome.

Mobile end points:
iOS, Android and Windows.

Answer 1

• I think first, you have to create a mock server which can act as proxy like forward the request that comes from mobile end-point to mock server to actual server and send back the response from actual server to keep a copy of the response in mock server and send it back to mobile

• While forwarding the requests you have to record the API requests and responses in the medium of your preference like DB or locally as file.

• Then whenever a request comes from mobile then match the request with expectation and send back the response right from mock server itself and if there's no match then let the request pass to actual server and to the above.

• If you would like to develop whole thing on your own then you have to choose a server side programming language like python or php etc.. and get the web server ready , probably you have to choose the DB like mysql or oracle to store the responses.

• You have to code the logic on your own to see if you can send back one of the existing available responses back to the mobile or become a proxy ( while recording ) between mobile and actual server.

• This kind of record , mock or forward/return approach is quite flexible, scalable and less time consuming.

If you would like to go with prebuilt mock servers then feel free to dig into the following popular products.

• https://wiremock.org
• https://mock-server.com
• https://learning.postman.com/docs/designing-and-developing-your-api/mocking-data/setting-up-mock/

Update:

Recommendation:

1. use free open source Php for mock server
2. use free mysql as db for mock server

you have other options as well like python and aws etc..

Proposed UI: (Hope the UI would be obvious and cut down the explanation)

You can choose one of the recorded responses as the one that needs to be sent back. Please see how the data is mapped in the proposed DB schema

You can add new API and it's probable responses or edit the added one

Proposed DB schema:

The DB schema diagram shows the Primary key and foreign key relationship between tables and it's always good to apply DB normalisation thumb rules while designing it.

Hope the schema is quite self explanatory

P.S:

I will think through and try to add any missing information to build a full fledged mock server