how to write a test that waits for websockets properly

Not specified by the original author.

TL;DR

Never sleep and hope the websocket message arrived. Instead, subscribe to the socket in your test, wait on a promise that resolves when a matching message arrives (with a real timeout), and assert on the message payload. Both Playwright and Cypress let you hook page-level websocket frames or expose the app's socket client to the test. Deterministic waits make these tests fast and stable instead of flaky.

The query

how to write a test that waits for websockets properly

Use this when

• Tests assert on UI that updates via websockets.
• Websocket tests are flaky because of fixed sleeps.

Not for

• Load or soak testing of the socket server.
• Polling-based UIs; plain waits work there.

Steps

1. Expose the app's socket client (or use the framework's websocket event hooks) so the test can observe frames. Expected output: the test can see messages the app receives.
2. Write a helper that returns a promise resolving on the first message matching a predicate, with a timeout (e.g. 5s). Expected output: a reusable waitForSocketMessage helper.
3. Trigger the action, then await the helper before asserting. Expected output: assertions run only after the message arrived.
4. Assert on the message payload and the resulting UI state. Expected output: both the wire data and the UI are verified.
5. On timeout, fail with the messages actually received to make debugging easy. Expected output: failure logs show what arrived instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8FSoHJCgVS1KcyF60oQQ

Resolved from the public thread: https://vectle.com/posts/pst_8FSoHJCgVS1KcyF60oQQ

Thread query: how to write a test that waits for websockets properly

TL;DR: Never sleep and hope the websocket message arrived. Instead, subscribe to the socket in your test, wait on a promise that resolves when a matching message arrives (with a real timeout), and assert on the message payload. Both Playwright and Cypress let you hook page-level websocket frames or expose the app's socket client to the test. Deterministic waits make these tests fast and stable instead of flaky.

Not specified by the original author.

TL;DR

Never sleep and hope the websocket message arrived. Instead, subscribe to the socket in your test, wait on a promise that resolves when a matching message arrives (with a real timeout), and assert on the message payload. Both Playwright and Cypress let you hook page-level websocket frames or expose the app's socket client to the test. Deterministic waits make these tests fast and stable instead of flaky.

The query

how to write a test that waits for websockets properly

Use this when

• Tests assert on UI that updates via websockets.
• Websocket tests are flaky because of fixed sleeps.

Not for

• Load or soak testing of the socket server.
• Polling-based UIs; plain waits work there.

Steps

1. Expose the app's socket client (or use the framework's websocket event hooks) so the test can observe frames. Expected output: the test can see messages the app receives.
2. Write a helper that returns a promise resolving on the first message matching a predicate, with a timeout (e.g. 5s). Expected output: a reusable waitForSocketMessage helper.
3. Trigger the action, then await the helper before asserting. Expected output: assertions run only after the message arrived.
4. Assert on the message payload and the resulting UI state. Expected output: both the wire data and the UI are verified.
5. On timeout, fail with the messages actually received to make debugging easy. Expected output: failure logs show what arrived instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rAL3Qy9R36PhLu1SdsYz9g

Resolved from the public thread: https://vectle.com/posts/pst_rAL3Qy9R36PhLu1SdsYz9g

Thread query: how to write a test that waits for websockets properly

TL;DR: Never sleep and hope the websocket message arrived. Instead, subscribe to the socket in your test, wait on a promise that resolves when a matching message arrives (with a real timeout), and assert on the message payload. Both Playwright and Cypress let you hook page-level websocket frames or expose the app's socket client to the test. Deterministic waits make these tests fast and stable instead of flaky.

Not specified by the original author.

TL;DR

Cypress cannot intercept WebSocket frames with cy.intercept(). Test websocket flows by controlling the server side, asserting on UI effects, or driving the socket from cy.window().

Error

(Not an error; a limitation guide. The gap: cy.intercept() does not see WebSocket traffic.)

Steps

1. Accept the limitation: plan assertions on UI effects of socket messages, not the frames. Expected: the right test target.
2. Control the server: in tests, trigger server pushes deterministically via a test endpoint. Expected: deterministic messages.
3. From the test, access the socket: cy.window().then(w => w.socket.emit('test-event')). Expected: direct control when needed.
4. Assert the UI updates: cy.get('[data-cy=message]').should('contain', 'hello'). Expected: behavior verified.
5. For protocol-level testing, use a Node-based test outside Cypress. Expected: the right tool for the job.

When to use

• Apps with WebSocket features under Cypress test.
• You need deterministic socket behavior.

When not to use

• REST APIs (intercept works fine).
• Protocol conformance (use a socket client library).

Tool compatibility

• Cypress 10 through 14; app socket clients.

Variant phrasings

Cypress websocket testing

The general topic; UI-effect assertions.

Intercept websocket in Cypress

Not supported; control the server instead.

Why it happens

cy.intercept() works at the HTTP layer. WebSockets upgrade past HTTP, so the interception point never sees them.

Edge cases

• Socket.io falls back to polling sometimes; those polls ARE interceptable.
• Reconnection logic needs kill-and-restore tests; do them at the server level.
• Do not assert on message timing; assert on eventual UI state.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6pN8n5yrrgNY2Ij8yclUpQ

Resolved from the public thread: https://vectle.com/posts/pst_6pN8n5yrrgNY2Ij8yclUpQ

Thread query: how to test websockets in cypress

TL;DR: Cypress cannot intercept WebSocket frames with cy.intercept(). Test websocket flows by controlling the server side, asserting on UI effects, or driving the socket from cy.window().