Testing WebSocket Endpoints in Spring Boot
Fast recall
Quick revision
Core answer
Whether the candidate can go beyond unit tests and write realistic WebSocket integration tests.
Only unit testing the @MessageMapping methods in isolation and missing the full message-passing pipeline including broker routing.
Mention testing SockJS endpoints (requires SockJsClient transport list), testing security by sending unauthorized connections, and using AssertJ awaits for async assertions.
Interview-ready guide
Interview answer
Unit-testing a @MessageMapping method directly tests a Java method, not a WebSocket endpoint. The broker routing, message conversion, STOMP security interceptors, and SockJS transport — the parts that actually break in production — are completely bypassed without a running server.
The correct test setup:
@SpringBootTest(webEnvironment = RANDOM_PORT)boots the full pipeline; useWebSocketStompClientwith aSockJsClienttransport to exercise the same connection path a browser would take- Async challenge: messages arrive on IO threads at unpredictable times; collect frames in a
BlockingQueueand assert withpoll(3, TimeUnit.SECONDS)— bounded timeouts fail fast without the flakiness ofThread.sleep
What to test:
- Happy path: client connects, sends a message, assert the expected response or side effect (database record, broadcast to other subscribers)
- Security rejection: send an invalid or missing token and assert
ExecutionExceptionis thrown; if yourHandshakeInterceptorhas a bug permitting anonymous connections, only a negative test catches it before production - User destination routing:
/user/queue/notificationssilently drops messages when the principal isn't bound correctly — no error, no log, just missing messages; a test confirming delivery validates the entire auth-through-delivery chain
Why negative tests matter most:
- A passing happy path test with a broken auth interceptor gives false confidence; the security test is the one that catches the most dangerous class of WebSocket bugs
- Broken user destination resolution is also invisible without a test: the server logs no error, the client receives nothing, and there's no indication of what went wrong
I recommend three tests per WebSocket endpoint as the minimum: broadcast flow, security rejection, and user-destination routing — these cover the three most common production failures.
Testing WebSocket Endpoints in Spring Boot
Direct Answer
Use @SpringBootTest with a random port and a STOMP client (StompSession via WebSocketStompClient) to connect, subscribe, and exchange messages in tests. Use BlockingQueue or CompletableFuture to assert received messages asynchronously.
Common Mistakes & Pitfalls
Only unit testing the @MessageMapping methods in isolation and missing the full message-passing pipeline including broker routing.
Check your understanding
Answer these without looking back at the article.
- How do you test WebSocket endpoints that require authentication headers?
- How would you test message ordering in a high-throughput WebSocket scenario?
- What is the difference between testing with the simple in-memory broker vs. a real RabbitMQ broker in tests?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.