Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments. 

Hi! My name is [Artem](https://kettanaito.com), and in this course I will teach you how to mock WebSocket APIs with [Mock Service Worker](https://mswjs.io). You and I are going to build a chat application mock-first, and you will learn how to intercept WebSocket connections, handle client and server events, and also test the code that relies on WebSocket in Vitest and Playwright. Let's go!

Introduction to Mocking WebSocket APIs with Mock Service Worker

Install Mock Service Worker (MSW)

Set up Mock Service Worker in the browser, (1) generate a worker script via the `npx msw init` command; (2) create `mocks/borwser.ts` and use `setupWorker()` to create a worker instance; (3) defer your application's rendering in `entry.client.tsx` by introducing an `enableMocking()` function that calls `await worker.start()`.

## Resources

- [Browser integration of MSW](https://mswjs.io/docs/integrations/browser)
- [`setupWorker()`](https://mswjs.io/docs/api/setup-worker)
- [ `worker.start()`](https://mswjs.io/docs/api/setup-worker/start)


Set Up Mock Service Worker in the Browser

To intercept any WebSocket connection in your app, create a _WebSocket link_ using the `ws.link()` API from MSW. Provide it a URL predicate and store the link in a variable. Then, add the `connection` event listener to your WebSocket link to know when a connection is being established. Provide the result of that event listener to your `handlers` array, and you're good to go!

## Resources

- [Intercepting WebSocket connections](https://mswjs.io/docs/basics/handling-websocket-events#intercepting-connections)
- [The `ws` API](https://mswjs.io/docs/api/ws)


Intercept a WebSocket connection with Mock Service Worker

The `connection` event listener of your WebSocket link exposes a bunch of useful parameters to you. One of those parameters is the `client` object that represents the intercepted WebSocket client that establishes the connection. 

Add a `message` event listener on that `client` to know when it sends any messages in your application. And yes, this is a regular event listener! This means you get a `MessageEvent` instance as a parameter, and can observe the data sent via WebSocket.

## Resources

- [Intercepting WebSocket client events](https://mswjs.io/docs/basics/handling-websocket-events#intercepting-client-events)


Intercept WebSocket Client Events with Mock Service Worker

Letting you know about the WebSocket connections isn't the only thing a WebSocket link can do. In fact, it also gives you a `broadcast()` method to send a message to all the connected clients. Let's use that to broadcast a chat message in our app across multiple open browser tabs.

## Resources

- [Broadcasting data to clients](https://mswjs.io/docs/basics/handling-websocket-events#broadcasting-data-to-clients)
- [`.broadcast()` API](https://mswjs.io/docs/api/ws#broadcastdata)


Broadcast a Mocked Message to All WebSocket Clients

Listening to the outgoing WebSocket client events is nice, but how about we _modify_ them?

Let's parse the incoming `MessageEvent` data using `JSON.parse`, modify it, and provide its stringified version to the `chat.broadcast()` call to broadcast a different data.

## Resources

- [`.broadcast()` API](https://mswjs.io/docs/api/ws#broadcastdata)


Modify WebSocket Client Events with Mock Service Worker

One of the reasons to mock any API is to get control over it. In this one, we will replay a chat conversation between two non-existing users by empoying everything we've learned so far.  To replay that conversation for a particular WebSocket client, we will use the `client.send()` API.

## Resources

- [`client.send()` API](https://mswjs.io/docs/api/ws#senddata)


Replay a WebSocket Chat Conversation with Mock Service Worker

As we send and handle more and more WebSocket events, it would be great to bring some type safety to the mix. But type safety along won't cut it. We need the runtime safety as well.

Luckily, `zod` is to the rescue. In this one, we will use `zod` to create a chat message schema and use it to create `createChangeMessage` and `parseChatMessage` utilities to help us develop and mock our WebSocket API.

## Resources

- [Zod](https://zod.dev/)


Make a Type-safe and Runtime-safe WebSocket Communication with Zod

Let's see how our WebSocket client reacts to the connection being closed. Use the `client.close()` method in the event handler to reliably reproduce client connection closures.

## Resources

- [Closing WebSocket client connections](https://mswjs.io/docs/basics/handling-websocket-events#closing-client-connections)
- [`client.close()` API](https://mswjs.io/docs/api/ws#closecode-reason)


Close a WebSocket Client Connection with Mock Service Worker

With MSW, you can use custom close codes that are otherwise unusable on the client. For example, in this lesson we will emulate a WebSocket connection closure due to a 1003 status code, which means that the server is unable to process the incoming data.

## Resource

- [`client.close()` API](https://mswjs.io/docs/api/ws#closecode-reason)


Use a Custom Close Code to Close a WebSocket Connection with MSW

Event handlers in MSW represent a WebSocket server. And it so happened a single server may manage a communication across multiple clients. Let's see how we can close multiple WebSocket client connections at once!

We can get access to the set of all connected WebSocket clients in the `chat.clients` property. From then, it's a matter of iterating over them and calling `client.close()` on individual clients.

## Resources

- [`.clients`](https://mswjs.io/docs/api/ws#clients)
- [`client.close()` API](https://mswjs.io/docs/api/ws#closecode-reason)


Close Multiple WebSocket Clients with MSW

Let's add some realism to our mocks. We can get the `server` object from the `connection` listener arguments and establish a connection to the actual WebSocket server by calling `server.connect()`. Once we do that, our event handler becomes a _proxy_ sitting in-between our client and the actual server.

## Resources

- [Establishing actual WebSocket server connections](https://mswjs.io/docs/basics/handling-websocket-events#establishing-server-connection)
- [`server.connect()` API](https://mswjs.io/docs/api/ws#connect)


Establish Actual WebSocket Server Connection with MSW

Now that we have the connection to the actual WebSocket server established, we can listen to any events sent from the server to the client. The thing is, our event handler in MSW will receive those events before the client does.

## Resources

- [Intercepting WebSocket server events](https://mswjs.io/docs/basics/handling-websocket-events#intercepting-server-events)


Intercept WebSocket Server Events with MSW

By default, once we establish the actual WebSocket server connection in the mock, all the server events will be forwarded to the client. You can opt-out from this default behavior by calling `event.preventDefault()` on any intercepted server event.

## Resources

- [WebSocket server-to-client forwarding](https://mswjs.io/docs/basics/handling-websocket-events#server-to-client-forwarding)


javascript

Prevent Server-to-client Message Forwarding in MSW

The WebSocket client events are also being forwarded to the original WebSocket server since we've called `server.connect()`. Luckily, to opt-out from this forwarding we have to do just the same—call `event.preventDefault()` on any client event we don't want to be forwarded to the server.

## Resources

- [WebSocket client-to-server forwarding](https://mswjs.io/docs/basics/handling-websocket-events#client-to-server-forwarding)


Send Mocked WebSocket Client Messages to the Original Server with MSW

Sicne we're involving an actual WebSocket server in our mock, what happens if that server disconnects? Well, the client connection will close, which is a bummer. Let's see how to listen and prevent original server's `close` event, and also conditionally fallback to MSW to act as the server if that happens.

## Resources

- [`server.addEventListener()`](https://mswjs.io/docs/api/ws#addeventlistenerevent-listener-options-1)


Prevent WebSocket Server Close Event with MSW

Mocking WebSocket APIs resembles how you use them in the actual code. This means that you can control the event flow for your client and server events as you normally would when using `EventTarget`. Let's explore how to use `event.stopPropagation()` and `event.stopImmediatePropagation()` to achieve behavior layering when mocking WebSocket events. 

## Resources

- [WebSocket event flow](https://mswjs.io/docs/basics/handling-websocket-events#event-flow)


Prevent WebSocket Event Propagation Between Listeners with MSW

When mocking a WebSocket connection in the browser, MSW takes charge of logging WebSocket events in the console. In this one, we explore the different log types and learn how to read the log output of your WebSocket links.

## Resources

- [WebSocket logging](https://mswjs.io/docs/basics/handling-websocket-events#logging)


Understand WebSocket Logs in MSW

Let's write an integration test for our `<Chat/>` component in Vitest and React Testing Library. 

The WebSocket interception in MSW requires a global `WebSocket` class. You are covered if you're using Node.js v22 or higher since that global class exists there. But for older versions, we will create a custom Vitest environment to polyfill it using `undici`.

## Resources

- [Vitest](https://vitest.dev/)
- [Undici](https://github.com/nodejs/undici)
- [Testing Library](https://testing-library.com/)


testing-library

Test WebSockets in Vitest with MSW

Let's write an end-to-end test for our chat application using Playwright. For this one, we will reuse the browser integration of Mock Service Worker to also run during the automated test.

## Resources

- [Playwright](https://playwright.dev/)


playwright

Test WebSockets in Playwright with MSW

In tests, mocking gives us a way to reproduce different network-related scenarios. Like in this lesson, we will create a runtime event handler for our WebSocket client messages to test a scenario when another user responds to a sent message in the chat.

## Resources

- [`server.use()` API](https://mswjs.io/docs/api/setup-server/use)


Override WebSocket Event Handling in Tests with MSW

Mocking WebSocket APIs with Mock Service Worker

[00:00] Hi, my name is Artem and in this course I will teach you how to mock WebSocket APIs with mock service worker and what's the best way to learn? That's right to build so you and I gonna build a chat application together where you will learn how to intercept WebSocket connections handle client and server events and also toggle between the full control of the WebSocket communication and augmented control where you will be modifying the actual server events coming in. As usual, mocking with MSW is standard based and works everywhere, both in the browser and in Node.js. We're also going to take a look how you would test your WebSocket applications on an integration level with VTest and on end-to-end level with PlayWrite, both utilizing the same MSW setup, event handlers, and sometimes overrides when we need different behaviors and tests. Buckle up because you've never developed and tested your WebSocket apps this way.

[00:53] Let's go!



https://app.egghead.io/api/v1/lessons/introduction-to-mocking-web-socket-apis-with-mock-service-worker~0rie4/transcript

[00:00] Let's start by adding MSW as a dependency in your project. Open the terminal and use your package manager to install MSW. I'm using pmpm, so for me it will be pmpm install msw. You can see that the package has been installed and can continue.



https://app.egghead.io/api/v1/lessons/install-mock-service-worker-msw-fefi6/transcript

[00:00] To intercept WebSocket connections on the client, we have to enable MSW in the browser. To do that, open your terminal and type npx msw init. This command will copy the service worker script that MSW needs to run in the browser into whichever public directory you provide. Since we have a remakes app, our public directory is located in the root level public folder, so I will provide it with public. If you are prompted to save the public directory, you can choose yes, and this will store it in package.json so the worker script stays in sync with whichever version of MSW you are using.

[00:40] You can verify this by going to the public directory and locating mockserviceworker.js file there. Now let's head to the app directory and create a new folder called mocks. In this folder create a new file called browser.ts. In the browser.ts module import setupWorker from msw slash browser. Create a new variable called worker and assign it the result of the setupWorker call.

[01:11] This will configure this worker object so you're able to control MSW in the browser to start and stop the interception or affect it by appending new request handlers. Lastly, export this worker object so you're able to reference it elsewhere. The setupWorker function accepts request handlers as an argument. Request handlers are functions responsible for intercepting requests and handling their responses. You can provide them inline over here, but instead let's go to the mocks directory and create a new file called handlers.ts.

[01:44] In here, export a new variable called handlers, which will equal an empty array for now. Head back to the browser.ts and let's import these handlers. And then spread them as the argument to the setup worker call. The browser integration is ready but now we need to start it. Go to the entry.client.ts module and create a new function called enableMocking.

[02:13] Mark this function as asynchronous and then await a dynamic import to mocks slash browser. In here, access the worker object that we created earlier and call awaitWorker.start. This will start the service worker in the browser. Since we don't want to have MSW running in production, let's wrap this logic in a condition, saying that only if process environment node environment is development, we're going to enable MSW. Starting a service worker in the browser is an asynchronous action, so to prevent the race condition between the worker start and our application rendering, let's wrap this rendering in the enableMocking function.

[02:59] Let's call this function and provide the then handler and move the rendering logic inside that handler. This way the application will only start when MSW is enabled and ready to intercept requests. To verify our browser integration for MSW, Let's run our Remix app, head to the browser, and open the DevTools. In the console, we should see the mocking-enabled message printed by MSW.



https://app.egghead.io/api/v1/lessons/set-up-mock-service-worker-in-the-browser~cxsnu/transcript

[00:00] To intercept a WebSocket connection, go to handlers.ts and import ws-prom-msw. The ws namespace stands for WebSocket and contains all sorts of useful utilities for you to intercept and handle WebSocket connections. Now call ws.link() to create a WebSocket link. This method accepts a URL, which is a WebSocket connection URL. Our application makes a connection to this made-up example.com slash chat WebSocket URL.

[00:32] I will copy it and use it here for my WebSocket link. Creating this link returns you an object that you can use to listen to this connection being established in your app and also handle incoming and outgoing events. It's a good idea to name this object appropriately based on the service you're mocking. In our case, it's the chat service. Now head to the handlers array and add a connection listener on the chat by calling chat.connectionListener, providing connection as the event name and a second argument being a function which is a listener.

[01:05] When the connection event is dispatched I will print to the console saying new connection. Now if we head to our app in the browser and open the DevTools we can see this new connection string being printed and also MSW printing this message letting us know that it intercepted a WebSocket connection to example.com.chat. What's happening here is our application establishes connection to this WebSocket URL. MSW intercepts that connection and tries to see if there are any WebSocket links matching that URL. It finds our chat link and dispatches the connection event, calling our listener and printing this message to the console.



https://app.egghead.io/api/v1/lessons/intercept-a-web-socket-connection-with-mock-service-worker~m790s/transcript

[00:00] When a user sends a message in the chat, our application handles it by sending this stringified payload to the WebSocket server. This payload represents the message, with its type, and data like the author of the message, the text, and a bunch of other things. If I try sending a message right now by typing hello and submitting this, I will see that the MSW prints this log over here about an outgoing event being sent, and it provides the reference to the exact message event that's been sent and its stringified payload. But there's nothing happening in the UI, because our application expects a confirmation from the server that it has received a message. Let's fix that.

[00:41] Go to the handlers.ts file and to our connection listener over here. In the argument to this listener, spread an object and access the client property. This property, this object, represents an intercepted WebSocket client. Now in the listener, call client addEventListener and attach a listener to the message event. The message listener receives a message event instance as an argument.

[01:08] So let's console.log that event. Now when I try to send the same message I will see the MSW log over here, but also the log from our connection listener right here, containing the message event that's being sent. To send data back to the client, let's head to the listener for this message and call client.send. You can send all sorts of things over the WebSocket protocol, like strings, blobs, and buffers. Our application expects to receive the message event from the server, confirming that it has received it.

[01:41] So let's forward it as is, by providing event.data to the client.send() method. Once I do that, and try sending a message again, I will see it appearing in the UI because now I can see in addition to this outgoing message, MSW notifies me that the client receives the mock incoming message and then handles it by rendering this message for our user.



https://app.egghead.io/api/v1/lessons/intercept-web-socket-client-events-with-mock-service-worker~86r45/transcript

[00:00] Here, I have multiple people using our chat application, but when one of them sends a message, the other one can't see that message at all. That is happening because MSW sends the confirmation only to the particular client that issued that message. That can be handy if you want to communicate with an exact client in your mocks. But in this case, it's not enough. To send the data to all the connected clients, replace client.send with chat.broadcast.

[00:29] Notice that we're referencing this chat object, the WebSocketLink that we created earlier, and its broadcast method. This method will send the given data to all the connected WebSocket clients. And with these changes, both our users can exchange messages in the chat and actually see each other's messages.



https://app.egghead.io/api/v1/lessons/broadcast-a-mocked-message-to-all-web-socket-clients~gkng9/transcript

https://app.egghead.io/api/v1/lessons/modify-web-socket-client-events-with-mock-service-worker~7nc3i/transcript

[00:00] Our event handler gives us full control over the WebSocket communication, so we can reproduce all sorts of network scenarios. For example, let's replay a chat conversation between two mock users. To do that, declare a new variable called John, and assign it an empty object that satisfies the user type that our application already has. Provide the properties needed for this user like the name property being John and avatar URL being public slash avatars one JPEG and also an ID and I will use an existing create ID utility. Copy this object and create a new user called Emily, adjusting the data accordingly.

[00:45] Now that we have our mock users, let's create the chat messages for them. I'll create a new variable called johnMessages, which is an array of strings. And I will paste in the messages that John will send in the chat. I will do the same for Emily, Emily messages, area of strings, and the messages from Emily. Now go to the connection listener over here, and let's, on the root scope of this listener, let's iterate over the John messages.

[01:14] So, Grabbing a particular John message by index. Then call client.send to send this message to this connected client, providing an object that satisfies the chat message payload type you already have, define the type message for this as message, and data being the actual message being sent. Here we're going to have author equal John, the text of the message equal to John message, the sent at to be date dot now, and also create an id for this message using the same createId utility. Because we can only pass strings, blobs, or buffers via the WebSocket protocol, let's wrap this message object in json.stringify. Like so.

[02:05] Now we can see both messages from John arriving in the chat, but they happen at the same time, which is not very realistic. Let's add a bit of a delay to how these messages are sent. Head back to the file and import the delay function from MSW. Now before we're sending this message from John, let's await a delay with 500 milliseconds as the duration and also after the message is sent, let's await another delay for 1000 milliseconds. Since the delay function is asynchronous and we want to await it, let's mark our entire connection listener as an asynchronous function.

[02:42] We can see now that the messages arrive one after the other, emulating a more realistic human-like typing. Next, let's check if there's any Emily messages in response to John's. I'll create a variable called EmilyMessage and try to look up the Emily message by the same index. If it exists, I will send it to the client using the same client on send. I will copy this JSON stringify payload here and I will adjust the messages author to be Emily and the message to be Emily message.

[03:14] To make this message more realistic, I will also add another delay of 1000 milliseconds. And now we can see an entire conversation play out between John and Emily, which are both non-existing users. And of course, our own message handling still works. Thank you.



https://app.egghead.io/api/v1/lessons/replay-a-web-socket-chat-conversation-with-mock-service-worker~69kbc/transcript

[00:00] Type safety is essential when it comes to any API communications. But in case of our WebSocket event handling, the messages we receive and send have the Any type. This is not very useful and can lead to a lot of runtime issues. But even if we cast this message to a narrower type, like the chat message payload we have, we still won't be completely safe. Although our message variable has the correct type now, in reality anything can be sent over the WebSocket protocol in addition to this object, like blobs or array buffers.

[00:29] And if that happens, our handling will fail. That is because type safety alone is not enough to ensure a proper WebSocket communication. We also need the runtime safety. Let's achieve that by using a library called Zod in TypeScript. Zod is a schema declaration and validation library and I already have it installed in my app.

[00:47] If you don't, open the terminal and run npm install zod to have it added as a dependency. Once you have it installed, head to the app directory and the utils directory and create a new module called message utils.ts. In that module, import z from Zod. Create a new variable called chatMessageSchema and assign it to z.object. This means that our chat messages will be objects.

[01:15] Z.object utility expects us to describe the exact shape of the object we shall be sending or receiving. I'm going to copy an actual chat message object right here and proceed with annotating it using Zod. So the type property is supposed to be the literal message string. And I will use z.literal to describe that. Next, the data property is an object.

[01:35] I will wrap it in z.object. The ID of the message can be any string, so I will use z.string to annotate it. I will turn the author property into another object, Also annotating its ID property as z.string and using it for the name property and the avatar property. The text of the message is also string, I will use the same utility here, and finally for the sent at, this is a timestamp, so it's z.number. Now our schema for the chat message is ready, and it's time to create some utilities to parse the message and also to create a new message.

[02:11] Declare a new function called parseChatMessage that accepts an argument data of type WebSocket data. You can grab this type from MSW. Inside this function, let's first check if the type of the data we're receiving is not a string, and if that's the case, let's ignore that message altogether. Next, let's create a variable called message and assign it the result of parsing this data string using JSON.parse. Then, call our chat message schema and its saveParse method, providing this message as an argument.

[02:48] And store this parsed result in the variable called result. If the schema parsing has errors, let's ignore this message. But if it doesn't, let's return the result.data as is. This is going to return the incoming message we provided. And finally, let's export this function to use it both in our mocks and the actual application.

[03:07] Now go to the index route of our app and replace this JSON.parse with our new parse chat message utility. We can drop this typecasting altogether. Now the message we receive is correctly annotated based on the types of our schema, but it can also be undefined in case of unsupported data types. So let's check for that. If the message is not defined, let's ignore it.

[03:27] We can finally remove this to-do And take a look that the message type we receive is actually type safe according to our schema. Now let's make it easier to create chat messages. Head back to the message utils module and declare a new function called createChatMessage. This function will accept an input argument, which is a partial type, from z.infer, and then the type of our chat message schema. We are using the z.infer utility to convert our actual chat message schema object from here to a TypeScript type to then use as a type of the input argument.

[04:02] Now inside this function, let's call chatMessageSchema and use parse, providing input as an argument. We are using the parse method and not the saveParse method because we actually want Zot to throw here if we're providing an invalid input. It's great that our input can satisfy the schema, but we still need to send a string over the WebSocket protocol. So in that case, let's return json.stringify and provide the input as an argument. And of course, export this utility function to use later.

[04:30] Now in our root loader, let's use the new create message utility. Let's head to the place where you're sending the message from the client, right here, and replace it with create chat message, providing the same message like this, and of course dropping the satisfies anymore. Our chat object can also have a media property right now for media uploads, but we don't have it in the schema right now. Let's head back to the message utils and add a new media property, which for now will be z.any. In the same way, let's head to handlers.ts and use our new create chat message utility here when we're recreating conversation between two mocked users.

[05:08] So create chat message providing this exact message as an argument. And the same for Emily. With these changes, we are using Zot to achieve the ultimate safety when handling our WebSocket messages. That includes our mocks right here, but also the actual chat implementation as well. And the cherry on top is that Zort provides us both type and runtime safety.



https://app.egghead.io/api/v1/lessons/make-a-type-safe-and-runtime-safe-web-socket-communication-with-zod~efw0y/transcript

[00:00] You can close the connection to any intercepted WebSocket client by calling client.close. You can see that in the UI we're getting this nice notification saying that the client has been disconnected. We can see this because in our root route we have this onClose handler that renders this toast message if we receive a close code that equals 1000, which stands for graceful WebSocket connection closures. But closing the client connection as soon as it actually connects is not very useful because it leaves our application non-interactable. So how about instead we close the client only when it sends a particular message in the chat.

[00:35] Let's head to handlers.ts and refactor this a little bit. I will remove this close call and in our message handler, let's remove this check here and instead use our parse chat message utility from earlier. So we will store the parse message in the variable called message. And if it's not a supported message, we will ignore it. But if it's a supported message, let's check the message data text to be close.

[01:01] And if it is, let's call client.close and stop the handling. So let's see what happens when I send the message close in the chat. See that the connection has been closed because MSW intercepted this outgoing client message, parsed it as a valid message, and saw that the text of that message was close, and then it called client.close() and prevented any further handling, so we never saw this message broadcasted in the UI.



https://app.egghead.io/api/v1/lessons/close-a-web-socket-client-connection-with-mock-service-worker~uc6iz/transcript

[00:00] Calling client.close() without any arguments stands for a graceful connection closure, the one that has 1000 as the close code. This is the only way to close a WebSocket connection on the client, but when writing handlers with MSW, we are describing the server, not the client. This means that we can pass a custom close code as the argument to client.close. For example, I can pass a 1003 as the close code, which stands for a connection error when the server is unable to process the data sent from the client. If I save this and type the close message again, I can see a connection error pop-up right here, also displaying the right close code, 1003.

[00:42] This is extremely powerful because client.close allows you to emulate different closure scenarios from the server, the ones you cannot otherwise reproduce on the client alone.



https://app.egghead.io/api/v1/lessons/use-a-custom-close-code-to-close-a-web-socket-connection-with-msw~r1rx7/transcript

[00:00] Using client.close() is really great if you want to close a particular WebSocket client. Like here, if I type close() in the chat, this client will disconnect. However, a different tab of the same application will have a different client instance, so this will still remain open. To close multiple WebSocket clients you need to get the reference to all those clients. You can do so if you access our WebSocket link, the chat object, and its clients property.

[00:27] This is going to be a set of all the intercepted WebSocket clients that match this WebSocket link. So here we can do for each, get access to each individual client, and call its client.close() method. Let's make this logic conditional so it only happens when a particular message has been set in the chat. Let's make it an uppercase stop message. Move this logic inside the if statement and do an early return.

[00:52] Now if any of the clients sends this stop message it will disconnect but it will also disconnect any other clients even if they're in a different tab.



https://app.egghead.io/api/v1/lessons/close-multiple-web-socket-clients-with-msw~zdwis/transcript

[00:00] Let's talk about how you can use MSW when you already have the actual WebSocket server. So here I've updated my client to reference a different URL that points to the WebSocket server I have running locally. Respectively, in handlers.ts I've updated the WebSocket link to point to a different URL as well so it would match that connection. And I've also removed any handling for that connection because I want the client events to be handled by the original server. But if I go to the chat and try to send something, I will see that nothing is happening.

[00:30] That is because by default MSW prevents the actual WebSocket server connections from being established. This is really handy when you want to develop mock first or test your application. But let's see how to change that. To establish the actual WebSocket connection, head to the connection listener and in the argument, access the server object. Similar to how the client object allowed you to control the particular intercepted WebSocket client, the server object gives you control over the actual server connection.

[00:57] So to establish this connection, call server.connect. Now if you head to the browser and open the DevTools and the Network tab you can see that there's an actual WebSocket connection established to the provided URL and you can see the messages here once we're going to send them in the chat. For example, hi, we will see the outgoing message and also the incoming message from the server.



https://app.egghead.io/api/v1/lessons/establish-actual-web-socket-server-connection-with-msw~uw7ag/transcript

[00:00] Once the actual WebSocket server connection has been established, we can handle the events sent and received from that server in a similar way like we did with the WebSocket client. To react to a message sent from the original server, you can call server.addEventListener and add a MessageEventListener. It will also accept the message event reference and we can handle it for example by logging it out in the console. So now if you go to the browser and send something in the chat, you can see that message actually being sent over the WebSocket protocol to the original server but also that message event instance being printed here in the console from our handlers.ts module.



https://app.egghead.io/api/v1/lessons/intercept-web-socket-server-events-with-msw~6icfn/transcript

[00:00] By default, when you establish the actual server connection, MSW will forward all client events to that server and all the server events back to the client. That ensures that the two can actually communicate. But you can opt out from that forwarding on the individual message level. To do that, go to the server message listener and call event prevent default. With this change let's head to the browser and try sending a message.

[00:27] Huh, we're not getting anything back but if we inspect the network we can see the server actually sending the confirmation back to the client. But what's happening here is that this confirmation triggers the message event on the server object, and since we are preventing that default message forwarding, it never reaches the client, never reaches our application. This is extremely powerful because now we are in charge of that server event. And one of the things we can do with that event is modify it. So let's use our existing parse chat message utility and provide it the event.data, the actual payload sent from the server.

[01:01] Store the parsing result in a variable called message, check if it's a supported message and if it's not, ignore it. And now to send a modified version of that message to the client, we would need to grab the client reference from the connection listener and call client.send. But before we do, let's modify that message. Let's do message, data, text, and assign it to an uppercase version of that same text. And then use the createChatMessage utility and pass the modified message as the argument.

[01:32] Now when we're going to send a message, like hello world, we will receive an uppercase version of it back. So what's happening here is that the original server sends that confirmation, and this triggers the message event on our server object right here. And then we prevent the default message forwarding from the server to the client by calling event.preventDefault() so then we can modify this message and send it back to the client using the client.send() method, providing a modified message as the argument, And keep in mind that you can prevent that message forwarding conditionally. For example, we can move this event.preventDefault call after checking if the message is supported. This will prevent the forwarding for supported messages so we can modify them, but bypass any other events sent from the server.

[02:18] The client will receive them as-is.



https://app.egghead.io/api/v1/lessons/prevent-server-to-client-message-forwarding-in-msw~v5jbk/transcript

[00:00] We can also prevent the default message forwarding from the client to the server in a similar way. This can come in handy if you want to modify the message sent from the client before it reaches the server. To do that, let's call client, add event listener, add the message event listener, and grab the event. Now call event prevent default to prevent this message forwarding. So now all the events that our client sends will never reach the server.

[00:27] They will short circuit on the MSW level. We can introduce the same message parsing, I will copy it from here. And now let's modify the message by changing the author's name to be MSW. Now to send this modify message to the server, call server.send() and provide it with a new message. Let's use the create chat message utility and pass the modified message right here.

[00:50] Now sending messages in the chat will replace its author to be MSW, exactly what was specified here in the modified message, because that is the only message that the actual server receives.



https://app.egghead.io/api/v1/lessons/send-mocked-web-socket-client-messages-to-the-original-server-with-msw~ggeu1/transcript

[00:00] It looks like our original WebSocket server is having trouble connecting our client. Because we've established the actual server connection by calling server.connect, all the events, including the close event, are forwarded from the server to the client. But that shouldn't stop us from developing our application. Let's add a CloseEventListener to the server by calling server.AddEventListener, providing close as the event name, and adding the listener function. This function will be called whenever the actual server is closing the connection.

[00:31] We can grab the event reference from the argument and call event.preventDefault. Calling this preventDefault method on the close event will prevent the propagation of this event to the client that will result in closing the connection. So with these changes we can see that our WebSocket client is active because we can type something in the chat. But if we do, nothing is actually displayed. Well that is because we're forwarding the client messages to the actual server over here, and since the server is closed it cannot respond with any event back.

[01:03] So let's improve this logic. We can check if the server is operational by accessing the server.socket instance. This is a raw WebSocket instance that represents the connection to the actual server. And we can check its ready state property that represents in which state this WebSocket connection is in. If it's in a state bigger than WebSocket.open, which means closing or closed states, let's instead forward this message from the client back to the client, basically making MSW act as the server.

[01:33] And if the server is operational, let's keep forwarding to the actual server as is. So now if I send a message, I can see that message displayed in the UI because although the server is closed, we are using MSW as the server sending this message back to the client.



https://app.egghead.io/api/v1/lessons/prevent-web-socket-server-close-event-with-msw~fb9bo/transcript

[00:00] Much like the WebSocket communication, the way you handle it with MSW is also event-based. Understanding how those events flow through your handlers and different listeners you attach is crucial to achieving the behavior you want. For example, here I have two connection listeners for the same WAPT socket link. And because unlike HTTP handling, there is no really a state of a WAPT socket connection being handled. So I will see both of these console.log statements printed right here in the console representing these connection listeners.

[00:31] The same is true for other event listeners. For example, I can add a message event listener on the client. In fact, let's add multiple of these, labeling them message 1, 2, also another listener in the different connection handler here. Message 3. And once I send message on our WebSocket client, I will see both message 1, 2, and 3 being printed representing these different message listeners on the client, even if they belong to different connections.

[00:59] So by default, the event handling nature in MSW is accumulative. All the events happen at the same time across all your listeners. That can be handy if you want to layer different behaviors on top of each other. But sometimes you want to opt out of that layering. You can do so by using the standard API to prevent event propagation in JavaScript.

[01:19] For example, if I head to this first message listener I can call event.stopPropagation. Now when the client sends the message I will see message 1 and 2 being printed because they belong here to the same connection listener, but message 3 will be ignored because it belongs to a different connection listener. In other words, I've excluded that client message event from being handled by any connection listeners by the one that's declared over here. But I can also prevent the same message event from propagating to a sibling client message listener by calling eventStopImmediatePropagation. Now if the client sends the message, it will only call the first message listener over here, ignoring the sibling listener because I've called stop immediate propagation.

[02:08] Take advantage of the layered event handling in MSW but also keep in mind that you can opt out from it by using event stop propagation and event stop immediate propagation to short-circuit the events. And don't forget that you can also do that conditionally, for example, based on the payload sent in the event.



https://app.egghead.io/api/v1/lessons/prevent-web-socket-event-propagation-between-listeners-with-msw~wtlvk/transcript

https://app.egghead.io/api/v1/lessons/understand-web-socket-logs-in-msw~urolv/transcript

[00:00] Here's what you need to test your chat application in integration level test with VDest. Let's start from the setup. Since we're using Remix that runs on feet, we can reuse the same vidconfig.ts in our test runner as well. This will give us the same plugins such as TypeScript path aliases and any other things we use in our code automatically be available during the test run. And if you need to customize the test framework itself, include this test property in your ViteConfig and provide the configuration that Vitest expects.

[00:31] Like right here, I'm telling Vitest to expose its functions as globals, so things like test, expect, before all, and so forth. I'm also specifying a path to a custom setup file, as well as a custom environment. So let's talk about those in more detail. MSW expects your environment to have a global WebSocket class, which is available in Node.js since version 22. But if you're running on older versions of Node.js, you can create a custom VTest environment to include that WebSocket class by yourself.

[01:00] So here we are providing the path to this custom VTest environment and let's see how it's implemented. Custom environment is just an object that satisfies this environment type from VTest that includes the most important method which is a setup method. In this method we will extend the built-in HappyDOM environment, so make sure to have it installed, and we will expose a global WebSocket property using the WebSocket class from Undiji. Undiji is an official implementation of Fetch and WebSocket in Node.js, and you can install it as a regular dependency as well. So here we're grabbing the WebSocket class, which is the same class that's been run in Node.js since version 22.

[01:38] Now that we've exposed this WebSocket class, our tests and the code that we're testing can create new WebSocket instances in the same way that it does in the browser. The next step is to create a Vitas setup file. Here in vitas.setup.ts, this is a regular Node.js integration for MSW. So we have a server instance right here, and we're using hooks like before all, after each and after all, to establish the interception, reset the runtime handlers that we may add in individual tests, and also stop the request interception once our tests are done. This server instance itself is just a result of calling setupServer with the request handlers, or event handlers in our case, that will act as happy path behaviors.

[02:20] For the purpose of this exercise, I actually went to the handlers and cleared any event handlers that we had before. This means that our test will have no happy path behaviors and we will add behaviors in each individual test. The way you structure handlers is absolutely up to you and you can refer to the MSW docs to learn more about that. Since automated tests allow us to replay different behaviors in our chat, it would be nice to export this chat websocket link so we're able to access it in tests and provision any behavior overrides. Now let's take a look at the test itself.

[02:54] So I have this chat.test.tsx file and right now it has everything we need to test our chat application. Let's write a simple test case that verifies that the message we sent in the chat actually appears visible in the list of messages. I will start from rendering our chat component. I will call render from React testing library and provide the chat component right here. The chat component expects the user prop which is the currently authenticated user.

[03:22] I'm gonna paste this mock user right here and click Save. Next let's grab our message input by creating a variable called message input that will be the result of calling screen get by label text chat message. And finally let's get a send button by locating it by its role, get by role, button, and also the name that will say send. Now let's interact with the chat. Let's send a message by calling event type into the message input and we're going to type the message hello world and finally let's submit this message by calling click on the send button.

[04:06] Now that we've sent our message in test, we expect it to appear in the list of messages for the user. To do that, let's create an assertion that awaits screen bind by role log, which will be our chat message, to have text content hello world. This concludes the action and the assertion phases of this test but there's one thing we're still missing, the setup phase. We need to describe the WebSocket behavior in this particular scenario. To do that let's head at the beginning of the test right before render, reference our server which is the MSW server and call use.

[04:45] This will prevent any behavior overrides that will take place in the network for this particular test. So here let's use the chat web socket link, add the connection listener, grab the client object, then listen to the message event on the client, which is going to happen when we're going to click submit in our test, add this listener, and just forward this event back to the client. In this test, MSW will act as an actual server by listening to outgoing messages and sending them back as a confirmation to any sent chat message. And finally let's verify our task passing by opening it in the terminal and running VDust. So what's happening here is that we're modeling a particular use case here.

[05:31] We're rendering the chat component, and we enter a particular message, submit it in the chat, and we expect that message to appear in the UI, which means it's visible for all the users.



https://app.egghead.io/api/v1/lessons/test-web-sockets-in-vitest-with-msw~9h866/transcript

[00:00] Here's how we can end-to-end test our chat application using Playwright. First, we have Playwright installed and configured. I'm using this basic configuration and provide the base URL so it's easier to navigate our application in tests and also spawn our application before the tests run using the web server command. Then to enable MSW during the playwright tests, I'm not doing anything extra, I'm still relying on our enable mocking function, basically the browser setup for MSW that we used to develop the chat application before. And finally in handlers.ts what I did I moved this happy path connection handler from my integration tests in Vitas to here so both the end-to-end and integration tests can reuse the same behavior.

[00:44] With this setup in place let's write first end-to-end test. I will add one in the end-to-end directory and call it chat.test.yes. Our end-to-end test will consist of three steps. First, sign in as a random user. Second, send the message.

[01:08] And third, assert the message in the UI. So I will visit the application by calling page go to slash and do the signing part. I'll click on the randomize button then on the join chat button and finally wait for the logout button to be visible indicating that the user has successfully logged in. Then I will send the message in the chat by locating the chat message input and typing hello world and after that clicking on the button that says send which should send the message event to the WAP socket server which in the case of our end-to-end test will be MSW. And finally to assert that the message is in the UI, I will grab the log element and also make sure that it has the hello world content, which is the content of the message that we're sending.

[01:56] Now we can run our end-to-end test using npm test end-to-end. This is a command I added to package.json, you can use whatever command you want. Effectively, this will run PlayWrite test. I can see the test passing, but let's also verify it by running PlayWrite in the UI mode. The UI mode will show us every step of the test as it's being run.

[02:18] So here I click to run all tests and wait for them to complete. Now that the test is also passing I can go through every individual step like this signing step or then typing the message and sending it, and also the message appearing in the UI over here. Meanwhile, behind the scenes, this test, our application in general, communicates with MSW instead of the actual server, taking the behavior in handlers.ts as the source of truth.



https://app.egghead.io/api/v1/lessons/test-web-sockets-in-playwright-with-msw~rdsus/transcript

[00:00] I have another test case that starts much the same. I render the chat component using John as the test user, and then I send this message, hi everyone, in the chat. In response to this message, however, I want to send another message from a different user and make sure that the chat component can render them both at the same time. Because this is a network behavior specific to this particular test case, I will add it as an override using server.useApi. Similar to the HTTP handlers, I can use runtime handlers to add overwrites for my WebSocket event handling.

[00:35] So here I will use the same chat WebSocket link, add the connection listener, grab the client reference, and add the client.event listener or the message event. I want the intercepted message from John be printed in the UI so I will do client.sendEvent.data. Now I want another user to post a reply to this intercepted message. I will use client.send again and use the create chat message utility and provide us with these arguments, creating a mock message from Ashley that says, hi John, how are you? The only thing that's left now is to write our expectations, the assertions.

[01:20] So I'll head to the end of the test. I will first grab all the chat messages by screen, find all by role, and use log as the role and make sure that there are two chat messages. The first one that has text content that says hi everyone, this is the message from John, and the second one that has text content from Ashley that says, I'm just gonna copy it from here. Hi John, how are you? Now I will run this test and I can see that it's failing.

[01:59] If I take a closer look at Y, I can see that there are actually three chat messages being present. The first two are the ones we expect in this test case, but this other one, the third one, is unexpected. It's another Hi Everyone message from John. It gets rendered in the UI because of the happy path handling right here. In our handlers.yes, we also have a connection listener and a client message listener that prints all the intercepted messages in the chat.

[02:27] Because I don't need this logic to run in my new test case, I will head to this test case and to my runtime override over here, and I will call eventStopPropagation. By calling eventStopPropagation, I'm telling my test that I want to handle client messages only in this way and no other way. And because server.use will prepend my overrides, they will trigger first, effectively canceling the happy path behaviors. With the propagation stopped, I can see both test cases passing. Now when I send this message from John over here, hi everyone, it will get intercepted by this overwrite listener here, dispatch the message event on the client, stop any propagation to any other listeners for this message event, render the intercepted message in the UI and also have this different message from another user rendered as well, which we assert by the end of the test having these two different message assertions.



https://app.egghead.io/api/v1/lessons/override-web-socket-event-handling-in-tests-with-msw~fb7hw/transcript

Mocking WebSocket APIs with Mock Service Worker

Artem Zakharchenko

Course Content