使用 Spock 框架进行无痛 WebSocket 测试

测试异步代码绝非易事。尽管如此，使用正确的工具集仍然可以实现简单性和可维护性。

许多 Spring Boot Web 应用程序要求您超越通常的 REST 端点并开始接受 WebSocket 连接。与此同时，简单的 JUnit 测试已经过时，突然间每个人都在谈论Spock的潜力。

所有这些变化听起来令人兴奋，您想尝试这种新颖的方法。
然而，如果应用不当，这些技术可能会适得其反，导致测试不稳定且难以调试——这是异步操作的通常代价。那么，如何预防呢？
继续阅读以了解一旦您了解如何针对常见的嫌疑人（例如竞争条件和误报），您的 WebSocket 覆盖范围是多么容易和令人满意。为了使这个过程更加顺利，请务必帮助自己获取 GitHub 上提供的源代码。
回声：如果所有协议都那么简单
首先设置 Spring 来处理传入连接。此任务需要处理程序 bean 和配置以将 bean 与地址相关联。
处理处理程序的最简单方法是扩展其中一个帮助程序类，例如TextWebSocketHandler。为了论证起见，我们将实现RFC 862：回声协议。需要注意的是，我们将忽略空消息，以使服务测试更有趣。
这是这样一个处理程序的样子：
public class EchoSocket extends TextWebSocketHandler {
@Override
public void handleTextMessage(WebSocketSession session,
TextMessage message) throws IOException {
if (message.getPayload().isEmpty()) return;
session.sendMessage(message);
}
}
然后，您需要一个WebSocketConfigurer实现来在特定地址下注册您的处理程序 bean。上面的处理程序被声明为 bean 并附加到/echo：
@Configuration
@EnableWebSocket
public class SocketConfig implements WebSocketConfigurer {
@Override
public void registerWebSocketHandlers(
WebSocketHandlerRegistry registry) {
registry.addHandler(echo(), "/echo");
}
@Bean
public EchoSocket echo() {
return new EchoSocket();
}
}
有了这两个类，应用程序应该在localhost:8080/echo接受 WebSocket 会话，并始终回复收到的文本。接下来要做的是开始添加测试以查看它是否有效。
第一次接触：连接到socket
Spock 没有提供打开 WebSocket 连接的简单方法，因此我们需要一个客户端库：

com.neovisionaries
nv-websocket-client
2.8

首先要验证的是连接是否被接受。如果我们让 Spring 选择一个随机端口来启动，我们需要知道这个值——所以我们用@LocalServerPort注入它。
此时，请记住强制立即断开我们在每个测试中使用的套接字。否则，随着测试数量和复杂性的增加，以意想不到的方式干扰的未关闭套接字的数量也会增加：
首先要验证的是连接是否被接受。如果我们让 Spring 选择一个随机端口来启动，我们需要知道这个值——所以我们用@LocalServerPort注入它。
此时，请记住强制立即断开我们在每个测试中使用的套接字。否则，随着测试数量和复杂性的增加，以意想不到的方式干扰的未关闭套接字的数量也会增加：
@SpringBootTest(
classes = SpringWsApplication.class,
webEnvironment = RANDOM_PORT)
class EchoSocketTest extends Specification {
@LocalServerPort int port
def "socket opens"() {
when:
def socket = new WebSocketFactory()
.createSocket("http://localhost:$/echo")
.connect()
then:
socket.isOpen()
cleanup:
socket.disconnect(WebSocketCloseCode.NORMAL, null, 0)
}
}
到目前为止一切顺利，测试通过，所以我们知道我们可以打开和关闭套接字。
当我们开始发送和接收消息时，问题就变得不那么明显了。
与普通的 HTTP 调用不同，WebSocket 通信不是以请求-响应的方式进行的。当文本消息发送到套接字时，您不应该期望同步响应。
Spock 基于交互的测试：Mocks 来了
在我们继续之前，让我们看一下将在本文其余部分使用的两种方法：

def openSocket() {
new WebSocketFactory()
.createSocket("http://localhost:$/echo")
.connect()
}
static def closeSocket(socket) {
socket.disconnect(WebSocketCloseCode.NORMAL, null, 0)
}

考虑到我们已经知道并查看客户端库中的 WebSocket 类，提交文本消息似乎很容易—— sendText(String message)。然而，我们仍然需要找到一种接收响应的方法。
没有receive()方法，因此必须注册一个WebSocketListener。
我们如何验证监听器是否被调用？Spock 文档有一整节关于基于交互的测试，他们的意思是使用模拟：

def "responds with original message"() {
given:
def socket = openSocket()
and:
def listenerMock = Mock(WebSocketListener)
socket.addListener(listenerMock)
when:
socket.sendText("Hello")
then:
1 * listenerMock.onTextMessage(_, "Hello")
cleanup:
closeSocket(socket)
}

因此，我们创建了一个模拟，将其添加为套接字侦听器，提交一条文本消息，并期望模拟只被调用一次，因为这就是Echo 协议的工作方式。然后，我们尝试运行测试，令人惊讶的是它失败了：
Too few invocations for: 1 * listenerMock.onTextMessage(_, "Hello") (0 invocations) Unmatched invocations (ordered by similarity): None

可能出了什么问题？我们正在发送一条短信并等待回复——但我们真的是这样吗？
在socket.sendText()之后，测试立即进入下一行以执行断言。它期望模拟已经被调用一次，而不是等待EchoSocket接收消息并响应。太好了——我们得到了一个比赛条件。
如果你在断言之前添加一个简短的sleep()，它可能会通过——但是你做错了两件事：
您使测试运行的时间超出了必要的时间；即，100 毫秒很可能比它需要的多。
您不能确定 100 毫秒总是足够的——每 10 次或 1000 次执行仍然可能失败，您和您的团队需要了解这是该测试的本质。就此而言，如果您遵循这条路径，那么您的所有 WebSocket 测试都是一样的。
BlockingVariable：对抗竞争条件的终极武器
上面提到的问题和原则证明了对同步机制的需要。一种将执行测试的线程与在响应到达后调用我们的WebSocketListener的线程进行协调。
Spock 提供了一个名为BlockingVariable的构造，在他们的文档中没有解释——可能是因为它相当简单。
为了简单起见，我们可以将此变量描述为给定类型值的包装器。该值的设置与任何其他设置器一样，但在调用get()时它会产生两种不同的结果——它要么立即返回该值，如果它已被设置，或者等待给定时间设置它并然后失败。
您可以考虑通过以下方式使用BlockingVariable ：
使用预期的类型和等待get()返回的最长时间来实例化它。
实现一个WebSocketListener将任何接收到的文本转发到BlockingVariable。
尝试获取断言块中的值。一旦它到达，您还可以断言文本是什么，如果它从未到达 - 对 get() 的调用有权使测试失败。

def "responds with original message"() {
given:
def latch = new BlockingVariable(0.5)
and:
def socket = openSocket()
socket.addListener(new WebSocketAdapter() {
@Override
void onTextMessage(WebSocket websocket,
String text) {
latch.set(text)
}
})
when:
socket.sendText("Hello")
then:
with(latch.get()) {
it == "Hello"
}
cleanup:
closeSocket(socket)
}

应该这样做——不再有竞争条件。测试被迫等待接收消息的线程响应。它也需要尽可能多的时间。设置值的那一刻，get()方法返回，所有剩余的断言都被执行。
随着您的测试套件的增长，请考虑使用一种实用方法替换上面的 and: 块，该方法可以打开一个套接字并将其一次性转发到一个闩锁。您不希望像下面这样的样板代码分散您对测试背后的逻辑的注意力：

def openSocket(latch) {
openSocket().addListener(new WebSocketAdapter() {
@Override
void onTextMessage(WebSocket websocket,
String text) {
latch.set(text)
}
})
}

所以你有它 - 有了你的第一个有意义和可靠的测试，你和你的队友没有更多的借口。现在是继续致力于自动化测试覆盖并继续推出所有基于 WebSocket 的惊人功能的时候了！
再次，请随意使用GitHub 上提供的源代码，祝您测试愉快！