It's not possible to unit test a WebSocket application
See original GitHub issueHi,
I’m migrating my Http4s
WebSocket application from 1.0.0-M23
to 1.0.0-M34
.
Now, as I shouldn’t create a WebSocketBuilder
myself, but it is provided by the server, how can I unit test my routes if they require passing a WebSocketBuilder
which I can’t create myself?
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Why won't unit tests connect to a websocket - Stack Overflow
When I run my unit tests I use the same code to create and run the server (once per test run) my tests...
Read more >Testing WebSockets for beginners - Scott Logic Blog
We are going to look at the characteristics of WebSockets, what they do, how to test them and investigate the art of the...
Read more >Writing Integration Tests for WebSocket Servers Using Jest ...
Writing Integration Tests for WebSocket Servers Using Jest and WS. WebSockets are very useful for ongoing communication between a client and a ...
Read more >Testing Websockets for Redis
Currently it is not possible to simulate more than one client at a time. Django's built in LiveServerTestCase can not handle more than...
Read more >25. WebSocket Support - Spring
Unlike HTTP, which is an application-level protocol, in the WebSocket protocol there is simply not enough information in an incoming message for a...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Making a method public or adding a method is binary compatible. We can take this in 0.23 😃
IIUC the main idea behind creating a
WebSocketBuilder
internally is that it should have the same lifecycle as the HTTP server.However, as long as the HTTP server builder doesn’t allow the users to use a custom instance, it should be fine to make the constructors public. For example, the current Ember builder takes a function:
If this is the only way to use a
WebSocketBuilder
and build a WebSocket application, I’d say it doesn’t make sense to hide the constructors from the users, and it will facilitate unit-testing where a server is not involved.Am I missing some other reason why these constructors have been made private?