Oh! I didn't mention this here yet, but I've been on a bit of a shipping spree:
Yesterday I published a fairly stable version of light-my-websocket, which does request injection testing for websockets, inspired by light-my-request.
https://npmx.dev/package/light-my-websocket
Later today I'll be publishing a package to assist with setting up an initial package release to configure OIDC Trusted Publishing and staged publishing.
If you don't know about injection testing, you should! So many ecosystems and tools will usually spin up a node.js server per test/suite to the use a fetch/http based test against it.
Why's this bad?
Because you're paying the cost of requesting to the kernel "hey, create this server and listen on some port, and give me that port", then every request is also a network connection that has to be spun up, written to and read from, and then torn down, server also needs to be torn down afterwards. These all go through many layers (runtime, operating system, kernel, etc)
Those layers are all separately tested by the operating system, so you can assume they work. What you want to test is your application logic: if I do this I get response blah
So why not just stub out the request & response channels & test with something like what a real client will use?
Switching a large suite from the typical setup to request injection testing will dramatically speed up your tests.
light-my-websocket does for WebSocket servers what light-my-request does for HTTP servers.
(Yes, I know WebSockets are technically tunnelled over HTTP, I was involved back when they were being standardised in like 2009-11)
If you don't know about injection testing, you should! So many ecosystems and tools will usually spin up a node.js server per test/suite to the use a fetch/http based test against it. Why's this bad? Because you're paying the cost of requesting to the kernel "hey, create this server and listen on some port, and give me that port", then every request is also a network connection that has to be spun up, written to and read from, and then torn down, server also needs to be torn down afterwards. These all go through many layers (runtime, operating system, kernel, etc) Those layers are all separately tested by the operating system, so you can assume they work. What you want to test is your application logic: if I do this I get response blah So why not just stub out the request & response channels & test with something like what a real client will use? Switching a large suite from the typical setup to request injection testing will dramatically speed up your tests. light-my-websocket does for WebSocket servers what light-my-request does for HTTP servers. (Yes, I know WebSockets are technically tunnelled over HTTP, I was involved back when they were being standardised in like 2009-11)
Emelia 👸🏻
RobertSE