How to mock network failures

[00:00 - 00:16] In the previous video, we discussed using NOC to simulate slow network responses, but another ethical edge case to test is failed requests. If our API code assumes every request will succeed, it may not handle connection on failures or survivors gracefully.

[00:17 - 00:36] This could lead to crashes or unexpected behaviors. NOC makes it easy to mock different types of failed responses. We can set a request interceptor to return a status like 04, not found or 500 internet survivor. We can also cause requests to timeout entirely or throw errors on certain endpoints.

[00:37 - 00:54] This helps validate that our code reacts appropriately, like retrying requests, login errors or notifying users. This is our test to simulate error responses. Similar to the other test we've written in this module, we created a NOC interceptor to intercept requests to get recipe API.

[00:55 - 01:21] The new upper method will look through the recipe list and for half of the items, it will return 200 status code. For half of the items in the recipe list , it will return an error using the dot reply with error. NOC can also use dot reply and then enter an error on the HTTP status code like 400 or 500. In the act and the set step of our test case, we are set that the response should be 200.

[01:22 - 01:47] And finally, we have another helper method, verify nutrition key exists and we pass the response body to this helper method. This helper method will loop through all the recipe list and to assert that the nutrition key exists in all the items. I'm going to write an run our tests and I expect this test to fail because we didn't handle that eight keys.

[01:48 - 02:03] And here it is, our test failed. We expected 200, but we'll go 500 internal service error, and our server error. Here I'm in the recipe service and we have two functions, the get recipe with nutrition that cause the get recipe nutrition promise.

[02:04 - 02:25] This is where we make our enrichment calls, where we make the call, when an error exists, all we do is to just reject it, but we didn't actually tell our application what it should return. So here I can take out this line and make it to resolve with an empty nutrition instead of just rejecting that error.

[02:26 - 02:34] In a production system, you also want to make sure that you log appropriately. When you have an error, you want to make sure you log error and the context that led to that error.

[02:35 - 02:57] With this, if I go ahead and run our test again, our test will pass because we 're handling this error that occurs when we make our every friends call. What we're saying is, if this request fails, simply return our recipe and the nutrition body nutrition should be an empty array.

[02:58 - 03:13] Our test run successfully without showing errors, always make sure you test for failure of HTTP requesting applications. Besides checking for the happy path, always check for the sad path. In the case of third party APIs at a minimum test for failed requests and slow requests.

[03:14 - 03:33] So your application can handle those testing sad paths with network failures and errors, revealed weaknesses in our code that our unit and integration tests didn't cover earlier. It's uncovered. This is where it's handling exceptions properly by simulating the unhappy scenarios that may occur on their reward conditions.

[03:34 - 03:38] We gain confidence our API is robust enough for production usage.