使用 Spring Cloud Streams 测试错误流

Question

我已经使用 Spring Cloud Streams 启动了一个小型微服务。

我只有两个流绑定，如下所示：

 cloud:

    stream:

      bindings:

        channelone:

          destination: org.queue.app.EventsOne

          contentType: application/json

          group: app

        channeltwo:

          destination: org.queue.app.EventsTwo

          contentType: application/json

          group: app

我使用 Serenity 开发了组件测试，并将通道注入到我想要发送测试消息的位置：

@Autowired

@Qualifier(Channels.EVENTS_ONE_CHANNEL)

SubscribableChannel eventsOneChannel

@Autowired

@Qualifier(Channels.EVENTS_TWO_CHANNEL) 

SubscribableChannel eventsTwoChannel

在哪里：

Channels.EVENTS_ONE_CHANNEL and EVENTS_TWO_CHANNEL 

只是定义为字符串常量：

@UtilityClass

public class Channels {

    public static final String EVENTS_ONE_CHANNEL= "channelone";

    public static final String EVENTS_TWO_CHANNEL= "channeltwo";

}

组件测试模块导入依赖项：

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-stream-test-support</artifactId>

</dependency>

我发送的消息如下：

eventsOneChannel.send(someMessage)

快乐的流程工作得很好。但是，我想测试侦听器无法处理消息时的错误流。

这是一个监听器的例子：

@StreamListener(Channels.EVENTS_ONE_CHANNEL)

@SendTo(Channels.DTO_GENERATED)

public BonusDTO receive(Message<String> message) {

    try {

        log.info("Received Event event with payload [{}]", message.getPayload());

        return toDto(message.getPayload());

    } catch (Exception ex) {

        log.error("Error converting Event to DTO", ex);

        throw new EventHandlingException(ex);

    }

}

当 try/catch 抛出异常时，错误由服务激活器处理：

@ServiceActivator(inputChannel = "org.queue.app.EventsOne.app.errors")

public void handle(ErrorMessage errorMessage) {

   log.info("Error");

}

运行应用程序时，如果没有 spring-cloud-stream-test，如果处理消息时发生错误，则会触发先前的服务激活并处理错误。

然而，在测试过程中并没有发生同样的情况。使用 spring-cloud-stream-test，当监听器抛出异常时，从错误通道激活的服务不会被调用。

我也想测试错误流。

这是 spring-cloud-stream-test 的限制吗？使用 spring-cloud-stream-test 时是否有任何配置、技巧或技巧可以将错误消息发送到错误通道？

Answer 1

我认为这里存在一个更大的问题，所以我会尝试将其阐述出来，希望能够提供一些清晰的信息能够使用 ServiceActivator 注释错误处理程序方法是框架提供的契约，这意味着它的测试是我们的责任。此外，您使用的机制甚至不是来自 Spring Cloud Stream，而是来自 Spring Integration。但无论如何，我质疑应用程序是否应该测试它，因为您无法在应用程序级别以任何方式影响它，因为它不是您的功能。再说一次，这是我的观点，我很想知道你的想法。在 Spring Cloud Stream 3.0.0.RC1（及后续版本）中，我们实际上已经弃用了spring-cloud-stream-test-supportGary提到的新测试绑定器。其原因记录在我刚刚提供的链接中，但请随时跟进问题。尽管它的用法有相当详细的记录，但这里是我们自己使用它的测试用例之一，供您参考。尽管参考文档中的示例显示了基于函数的消息处理程序，但它的工作方式与基于注释的消息处理程序（这就是您正在使用的）相同。说到基于注释的编程模型，请参阅我们刚刚发布的以下博客（查找更多内容，因为它们正在工作中），其中我们阐述了为什么我们要放弃基于注释的编程模型，我认为您也应该开始考虑更改您的代码。毕竟，所有更改几乎相当于删除所有注释并稍微更改消息处理程序方法的签名以表示为函数 beanhttps://spring.io/blog/2019/10/14/spring-cloud-stream-demystified-and-simplifiedhttps://spring.io/blog/2019/10/17/spring-cloud-stream-functional-and-reactivehttps://spring.io/blog/2019/10/25/spring-cloud-stream-and-spring-integration我之所以这么说的原因有很多，但是您上面的代码和您表达的担忧再次提醒我为什么我们要放弃这种编程模型。我将在这里停下来，因为我相信这里有很多东西需要消化，但鉴于我刚才所说的内容，请随意跟进更尖锐的问题。

Answer 2

spring-cloud-stream-test 支持非常基本的测试绑定器；它不具备真正活页夹的所有功能。