How to test WebSocket using ws lib?

[onmax]

Hello,

I have a project where I have implemented a WS client. Under the hood I use @openrpc/client-js, which uses isomorphic-ws, which uses ws@v7.

ws is the Node implementation for Node and I am having a hard time trying to create test using msw.

Here is the test I have:

import { http, HttpResponse, ws } from 'msw'
import { setupServer } from 'msw/node'
import { NimiqRPCClient } from 'src'
import { afterAll, afterEach, beforeAll, describe, expect, it, vi } from 'vitest'

const api = ws.link(client.ws.url.href)

export const handlers = [
  api.addEventListener('connection', ({ client }) => {
    console.log('Intercepted a WebSocket connection:', client.url)
  }),
]
const server = setupServer(...handlers)

beforeAll(() => server.listen())
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

describe('test for subscriptions with mock web socket', async () => {
  it('subscribe to hash blocks', async () => {
    // My lib which uses ws
	const client = new NimiqRPCClient('http://localhost:8648/ws')
    const { next, close } = await client.blockchainStreams.subscribeForBlockHashes()
    // TODO Tests
  })
})

If I run it like that I will get an error and the connection is never opened:

[MSW] Warning: intercepted a request without a matching request handler:

  • GET http://localhost:8648/

So, I have implemented an HTTP handler which I have added in the handlers array:

export const handlers = [
http.get('http://localhost:8648/ws', ({ request }) => {
    if (request.headers.get('upgrade') === 'websocket') {
      return new HttpResponse(null, {
        status: 101,
        headers: {
          'Upgrade': 'websocket',
          'Connection': 'Upgrade',
          'Sec-WebSocket-Accept': 's3pPLMBiTxaQ9kYGzzhZRbK+xOo=',
        },
      })
    }
  }),
// ...
]

With that, it is seems to be returning the response but the web-socket and the connection is never open.

Not sure, why ws is making an http request (I guess for hand-shaking) and I am not sure how to solve the issue.

I also tried to mock the isomorphic-wslibrary:

vi.mock('isomorphic-ws', async () => {
  return {
    default: WebSocket,
  }
})

But none of the solutions have worked...

I would like to know if anyone has ever manage to test the lib ws using msw. I couldn't find anything in GitHub.

Thank you!

[kettanaito]

Hi, @onmax.

What you are doing in the first snippet should work. I believe MSW should handle the handshake request, but if you are still getting it as unhandled you can disregard that for now. Handshake succeeds, the WebSocket instance is created, and then ws.link() kicks in.

The WebSocket mocking works with ws as we use it extensively in our test suite. Here's one example. You can search in that repo for more.

The issue must be someplace else. Can you please submit a minimal reproduction repo for this? Then I can take a look. Thanks.

[onmax]

Thanks. I will look into your example!

If I am unable to see the issue I will create a minimal repro :)

[kettanaito]

That would be most welcome! Thank you.

[onmax]

Here is my repro: https://github.com/onmax/open-rpc-msw

You can find all the relevant info in the readme.

Thank you very much for looking into it :)

[babutabhavya]

Facing the same issue.

[kettanaito]

Update

I've taken a look at https://github.com/onmax/open-rpc-msw, here's my findings.

1. WebSocket handler URL was incorrect. You need to provide the matching URL, which in case of your client is ws://localhost:8545/ws as it appends the /ws pathname.
2. You depend on @open-rpc, which depends on isomoprhic-ws, which in turn depends on ws. None of them use the global WebSocket class. That is why MSW cannot see that WebSocket connection. It's made using the WebSocket class from ws, which is never set on the global scope.

Apart from this, your initial approach for handling the HTTP handshake via http.get() handler was the right call, only adjust the request URL, as it's http://localhost:8545/ws.

I can see that MSW throws on constructing a mocked 101 Continue response. I thought we've fixed non-configurable status codes. Apparently something got unchecked.

A quick verification that this one is on our end:

expect(new HttpResponse(null, { status: 101 })).toHaveProperty('status', 101)

RangeError: init["status"] must be in the range of 200 to 599, inclusive.

I will open a bug regarding this and ship the fix soon.

What does this mean?

Even with my fix, your setup still won't work. MSW currently doesn't support arbitrary WebSocket clients. I don't want to recommend you override globalThis.WebSocket either. Perhaps our best bet is to support something like this:

import { WebSocket } from 'msw'

ws.link(url, {
  WebSocket,
})

But this has its issues too, import order being the most important one (your ws.link will have a chance to patch WebSocket way after your tested code has imported the unpatched version).

[onmax]

Amazing! Thank you!

[kettanaito]

@onmax, another good point you brought up is that handshakes should really be handled by your WebSocket link. You shouldn't be handling them via http.get() yourself. Why this wasn't implemented before is because the global WebSocket API doesn't integrate such a handshake, or it isn't publicly visible, at the least. Third-party packages like ws can do whatever makes sense for their context, and so some of them can have manual HTTP handshake like you're experiencing right now.

[onmax]

So, if I understand the best solution for now is to patch isomorphic ws with globalThis.websocket to use node WebSocket until msw supports custom ws clients?

[kettanaito]

Since you aren't relying on the global WebSocket API anyway, you are better off patching it instead:

// vitest.setup.ts
import { WS } from 'isomorphic-ws'

Object.defineProperty(globalThis, 'WebSocket', { value: WS, enumerable: true })

Make sure to load this as a test's setup. It's essential this gets applied before your test suite loads. Once you do this, MSW will be able to see those connections. The next release will give you the ability to handle handshakes manually, which you should also do for now.

[kettanaito]

Track the progress and contribute to HTTP handshake handling here: #2436. Thanks!