 <p>As I see it, you have a few options, depending on exactly what you want to achieve in your tests now, and what you might want to be able to do in the future.</p> <p>1) If your test does not need the websocket configuration at all, change it to point at a custom context configuration that does not include the <code>WebSocketConfig</code>.</p> <p>2) If your test needs the websocket config, but you don't need the broker relay (I can't see why it would be required in a test), you could add another Configuration for testing that uses <code>registry.enableSimpleBroker("/topic", "/queue/")</code> instead of <code>enableStompBrokerRelay</code>. Then there will be no TCP connection to the broker. The obvious disadvantage with this approach is that you are not testing your actual config, and that you are duplicating the destination prefixes.</p> <p>3) Run an embedded STOMP broker for your tests. I'm not 100% certain such a thing exists - I know ActiveMQ has STOMP support and some support for <a href="http://activemq.apache.org/vm-transport-reference.html" rel="nofollow">running inside a VM</a>, but I haven't tried this with STOMP. If possible, the advantage of this approach is that your tests would be testing something very close to the real code.</p> <p>4) You could customise the STOMP broker relay to such an extent that you have full control over what your application receives from the broker. You can customise the <a href="https://github.com/spring-projects/spring-framework/blob/master/spring-messaging/src/main/java/org/springframework/messaging/simp/stomp/StompBrokerRelayMessageHandler.java" rel="nofollow"><code>StompBrokerRelayMessageHandler</code></a> which manages the connection to the relay broker by adding a Configuration class that extends <a href="https://github.com/spring-projects/spring-framework/blob/master/spring-websocket/src/main/java/org/springframework/web/socket/config/annotation/DelegatingWebSocketMessageBrokerConfiguration.java" rel="nofollow"><code>DelegatingWebSocketMessageBrokerConfiguration</code></a> in order to override the <code>stompBrokerRelayMessageHandler()</code> method. For example, you can set the TCP client it uses to your own implementation of <code>TcpOperations</code>. Below is an example TCP client that simply does nothing, i.e. makes the Handler think it is connected, but cannot receive or send messages.</p> <pre><code>@Override public AbstractBrokerMessageHandler stompBrokerRelayMessageHandler() { AbstractBrokerMessageHandler handler = super.stompBrokerRelayMessageHandler(); if (handler instanceof StompBrokerRelayMessageHandler) { StompBrokerRelayMessageHandler stompHandler = (StompBrokerRelayMessageHandler) handler; stompHandler.setTcpClient(new TcpOperations&lt;byte[]&gt;() { @Override public ListenableFuture&lt;Void&gt; connect(TcpConnectionHandler&lt;byte[]&gt; connectionHandler) { return new CompletedListenableFuture&lt;&gt;(null); } @Override public ListenableFuture&lt;Void&gt; connect(TcpConnectionHandler&lt;byte[]&gt; connectionHandler, ReconnectStrategy reconnectStrategy) { return new CompletedListenableFuture&lt;&gt;(null); } @Override public ListenableFuture&lt;Void&gt; shutdown() { return new CompletedListenableFuture&lt;&gt;(null); } }); } return handler; } </code></pre> <p>Note that <code>CompletedListenableFuture</code> is just an implementation of <code>ListenableFuture</code> that is done after construction, and immediately calls any callbacks passed to <code>addCallback</code> with the value passed into the constructor.</p> <p>The point here is that you can easily customise the exact behaviour of the broker relay components, so you can control them better in your tests. I am not aware of any built-in support to make this kind of testing easier, but then again the websocket support is still pretty new. I would suggest that you look at Rossen Stoyanchev's excellent example project <a href="https://github.com/rstoyanchev/spring-websocket-portfolio" rel="nofollow"><code>spring-websocket-portfolio</code></a>, if you haven't done so already, as it includes several examples of how to test the websocket configuration at different levels (just one controller, loading the full context, running an embedded server, ...). Hopefully this is also helpful for deciding how you want to test your application, and what you might need to customise to do it.</p>