Midway: Simplifying Mocked Responses

http://i2.wp.com/www.datadependence.com/wp-content/uploads/2016/03/MOCKS-1.jpg

This blog content assumes that you have basic knowledge of Test Armada’s open source mocking fleet Midway and have gone through Midway’s training 101 and 201.

Testing and debugging applications in isolation by removing all underline dependencies is extremely powerful — which leads to the use of mocks. Though mocking is very powerful, it can be very complicated and strenuous at the same time especially when dealing with test cases or scenarios that may require mocking tens of external services and may result in tests to be:

• harder to understand
• harder to maintain

Mocks complexity increases when multiple Rest APIs are called multiple times with different data expectancy.

What if I tell you that using Midway’s Mock from Container feature you can kiss goodbye to most of the complications when creating mocks for complicated scenarios? If this excites you, read along…

When creating mocks either with inline test cases mocks or via using mock servers; the biggest challenge for complicated test cases is to set mocks (based on the number of times a mocked API is being called and returning separate data set each time) and maintain them later specially if the feature under test is constantly evolving. Midway’s Mock from Container feature enables all the mocked responses to be returned from a specific data container when using Midway-Server for mocking and is completely de-coupled from test case implementation which makes maintaining them a piece of cake.

How it Works?

Scenario: Let’s say your test case or scenario requires to mock two GET Rest APIs /api/message and /api/product/getStatus and both the endpoints are called three times each. For the first end point you always want to return the same data (in JSON) with HTTP code 200 while for the second endpoint you want to return the same data for the first and third call (in html) with HTTP code 200 and a different data for the second call (in JSON) with HTTP code 201.

Implementation: Create a folder under the mocked-data folder of your test directory (this folder name is configurable when you start your Midway-Server by passing mockedDirectory option) by the name test1. Under this folder add the following files for your mocked response.

1. api-message-GET.json - This will be returned for all the calls for the first endpoint with default HTTP response code 200
2. api-product-getStatus-GET.html - This will be returned for all the calls for the second endpoint with default HTTP response code 200, except for the second as it has its own file
3. api-product-getStatus-GET-2-code-201.json - This will be returned for the second call for the second endpoint with response code 201.

Through Midway object, Midway-UI or via REST API — the SetMockId API could be called to set the value:

midway.setMockId(“test1”);
or 
curl http://localhost:8000/_admin/api/midway/setMockId/test1

Explanation: The underline Midway mock service automatically figures out the file extension so that you do not have to specify it. If you have the same file with multiple file extension than the following order is used:

• JSON
• HTML
• TXT
• First file encountered of any other extension.

File names with mocked response data is created based on the Rest API that is being mocked, for example for Rest API /api/message file name is api-message-GET.json. The method name is used to differentiate between various REST methods as same Rest API path can support two different REST methods. If in the above example I want to return a different response for the first request than I would add another file with the name api-message-GET-1.json. Then for first call api-message-GET-1.json will be used and for all other calls the default file api-message-GET.json will be used. For POST call the name of the file will simply change to api-message-POST.json.

TIP! Once the midway.setMockId(“test1”) API is called, Midway only looks for the responses under the test1 folder. If it does not find the response, it will return 404 with the file name that was not found. Midway internally keeps track of the number of times each individual endpoint is called after midway.setMockId(“test1”) API is called and first looks for the file with count specific name such as api-message-GET-1.json, if it does not find the said file then it looks for the default file which is api-message-GET.json.

Good To Know

If SetMockId is set, then custom file path

 midway.util.respondWithFile(this, reply,{filePath:‘./default.json’}
); 

and file based on URL path ../mocked-data/api/message/get/default.json are ignored for the mocked response. Here is the order followed for file lookup:

• SetMockId
• Custom File Path for default or variants endpoints.
• File based on URL Path for default or variants endpoints.

Other Utilities

After setting the SetMockId, you may need to reset the URL count or may need to reset the mock id to go back to either custom file path or file path based on URL or variants. To do so, you can either use the UI, Rest APIs or Midway commands:

• ResetCount — To reset the URL called count to zero and does not impact current mock id. After this, Midway will start counting the endpoints call count from zero.

midway.resetCount();
or 
curl http://localhost:8000/_admin/api/midway/resetURLCount

• ResetMockId — This removes the current SetMockId and sets the URL counts to zero

midway.resetMockId();
or
curl http://localhost:8000/_admin/api/midway/resetMockId

• GetMockId — To get the current mock-id set for Midway-Server

midway.getMockId();
or
curl http://localhost:8000/_admin/api/midway/getMockId

• GetURLCount — To get URL count for all Rest APIs mocked by Midway-Server

midway.getURLCount();
or 
curl http://localhost:8000/_admin/api/midway/getURLCount

Advantages of Mock from Container approach:

This feature is very handy when you want to stub all the endpoints for a particular test without manually writing the paths for those endpoints. Generally applicable in scenarios where one flow requires calling one or more endpoints multiple times with different data results expectancy.

• Stub Multiple Rest APIs — Drop as many files in the mock folder as your scenario requires based on the Rest API path.
• Mock Rest APIs with Multiple Calls & Different Data Expectancy — Add the call count to the file name and that file will be returned based on the time the API is being called.
• Reduced Test Complexity — Test are decoupled from the setting mock responses and thus making test easy to read.
• No Variants — For multiple calls to the same API, a new file can be added for a different data set and thus removes the need of creating any variants.
• Easy Maintenance — If any changes happen, only files content or name needs to be changed.
• Developers Paradise — Makes developing a feature super easy as no code needs to be changed if mock behavior needs to change.

Stay tuned for future blogs for in-depth architecture and features explanation. In the meantime, please feel free to go over Midway’s documentation or to try download it from here.

Related Blogs: Midway: Walmart’s mocking journey…