00:00 Let's learn how to set up MSW together, so feel free to follow me while you're watching this video. So here we have a getAuth token, and the purpose of this function is to fetch some authentication token from somewhere, to be specific from this made-up server URL. And then it has some response handling, some basic error handling, and in the end reads responses.json and returns the

00:19 fetched token. So obviously we want to mock this fetch request for two reasons. First, to draw this test boundary between this function and its test, and the actual server. But then also to gain control over what the server returns, so we're able to tap into all of these different behaviors

00:38 during the tests. So I will start from installing MSW. In the terminal I will run npm install msw. This is going to add mock service worker as a dependency to your project. It's going to take some time, but once it's done we will proceed. And it's about done. Next thing I'm going to do is

00:57 create the file called handlers.ds. This file will serve as the source of truth for the mock network behavior. In this file I will create a variable called handlers, which equals to an empty array

01:10 for now, and I will export it for later. Now let's describe what is called a request handler. Request handler is a function responsible for intercepting requests and handling their responses. In MSW you can create request handlers by importing namespaces like HTTP or grepql from MSW.

01:30 So here I will create an HTTP handler, which means this handler is for HTTP requests, and as the method it actually accepts the methods of this HTTP request. But for now I will call a special all method, which will capture all HTTP requests regardless of their method. The first

01:46 argument and the second argument. Let's explore those. So the first argument is the path. Basically the path to your resource or maybe a regular expression or a special token. I will use a wild card token, which means match any requests with any path. And the second argument is the resolver

02:02 function. This is the function responsible for handling this intercepted request. And you can handle requests in different ways. You can return a mock response, you can just observe this request, maybe fire a side effect, or you can perform the request as is and patch in the original response

02:18 with mock data. Anything you want. But for now let's just grab a reference to the request object. This is the intercepted request, the Fetch API request instance, and just console.log the requests method and request URL. So this is a very basic request handler. We describe what requests to

02:37 intercept and how to handle them. So for now we will just print any outgoing requests in test in the console. Now what's missing is to actually enable the request interception. For that I will create a setup file, vtest setup.ts. I will then hook this file in the VTEST config by providing a

02:57 setup files option and I will link it to vtest setup.ts. This way VTEST knows that it needs to run the setup file before the test run starts. In the setup file I need to enable MSW. To do that I

03:12 will import a function called setup server from msw slash node because here we're using MSW in a Node.js process. Your VTEST tests are still a Node.js process. And I will create a variable called server that equals to setup server call. This is going to do, it will configure the server

03:29 object that will be our API to control the request interception, to stop it, to modify it, to start it and so forth. Now the setup server function can accept the list of handlers. So let's import the handlers that we defined before. Handlers from handlers.js and I will spread this handlers array

03:47 as the arguments to the setup server call. Now even though the server object is configured the API mocking is not active yet. For that I will add a before all hook where I will call server dot listen. This will actually start intercepting the requests and run them through all the request

04:05 handlers that we have to see if there are any matching and to see how they handle that request. To make my experience a little better I will provide an on unhandled request option to this listen call and it will equal to error. This means that whenever MSW encounters a request during a

04:20 test run that was not present in your handlers, it will print a nice error message for you to let you know. Next I will add an after each hook and here I will call server dot reset handlers. Similar to how we were setting console spies for example between the tests so they don't leak

04:38 between the tests and don't affect unrelated tests, I will reset any handlers that I may introduce in individual tests. We're going to explore that a little later. And finally I will add the after all hook where I want to clean up completely and stop the request interception by calling server dot

04:55 close. And this concludes the test setup you need to have to integrate MSW in a vTest test suite.