How to mock slow network

[00:00 - 00:10] When building API tests, we want to simulate build-wall scenarios as closely as possible. One such case is slow or unreliable network conditions.

[00:11 - 00:29] If our code relies on external services or data sources, we need to verify it can properly handle slow responses without crashing or producing errors. This is where NOC comes in very handy. NOC allows us to intercept HTTP requests and simulate different types of network behavior.

[00:30 - 00:38] We can introduce artificial delays on responses to see how our code reacts. These better mirrors what could happen in production.

[00:39 - 00:56] As the best part is, it's not sufficient to only test the ideal happy path scenarios. We must also validate sad paths and edge cases, like requests timing out or servers being unavailable. If we fail to account for these, our software may not be robust enough for production use.

[00:57 - 01:20] We added a new test to our test suite. We want to test when we have slow network that our HTTP endpoint still returns our list of recipes containing nutrition. And following the arrange act as a pattern, in the arrange step, we created a match list similar to what we did in the previous lesson. And also, we created our network interceptor using NOC.

[01:21 - 01:32] We intercept get recipe requests and we have a new helper function here. Create request interceptor with slow network. Request interceptor with slow network.

[01:33 - 01:54] Pretty much does the same thing as create request interceptor, where it looks through recipe list and create network interceptors. But you will notice a new option here, which is delay connection with this option. We can choose to delete connection. And we're using random when random is true, we'll delete the connection by 6, 000 milliseconds.

[01:55 - 02:22] And back to our test. By default, just test time out in 5,000 milliseconds. I added a comment here. So that means this test case will fail irrespective of whether our application is robust enough and handles this edge case. What we need to do is tell just that it shouldn't timeout after 5,000 milliseconds. And to do that, we added a taught argument to test function.

[02:23 - 02:43] And this third argument configures the timeout of our test. Another solution is to add the test timeout to just config file. This accepted number and this will apply to all tests. But because this change just applies to one test I prefer to add it in here.

[02:44 - 03:13] I'll go ahead and run these tests. You should run without drawing any errors. Great, our tests completed without. By intercepting request with NOC, we gain full control over the network variability. We can delay responses by seconds, return errors or fail request entirely. This helps surface any issues in our code's ability to gracefully handle slowness failures. In the next lesson, I'll demonstrate how to introduce network failure