使用Spring云流测试错误流

Question

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

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

 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测试的情况下运行应用程序时，如果出现处理消息的错误，则会触发之前的服务激活并处理该错误。

但是，在测试期间不会发生同样的事情。使用spring-cloud-stream-test，当侦听器抛出异常时，不会调用从错误通道激活的服务。

我还想测试错误流。

这是Spring-Cloud-Stream测试的限制吗？在使用spring cloud stream测试时，是否有将错误消息发送到错误通道的配置（技巧或提示）？

谢谢

Answer 1

spring cloud stream测试支持一个非常基本的测试绑定器；它没有真正活页夹的所有功能。

Answer 2

@Joao Pereira我认为这里有一个更大的问题，所以我会试着把它摆出来，希望能提供一些清晰

>

使用ServiceActivator注释错误处理方法的能力是框架提供的合同，这意味着它的测试是我们的责任。此外，您使用的机制甚至不是来自Spring Cloud Stream，而是来自Spring Integr。但无论如何，我质疑应用程序是否应该测试它，因为您不能在应用程序级别以任何方式影响它，因为它不是您的功能。同样，这是我的观点，我很想看看你的想法。

春云流3.0.0。RC1（及其后续版本）我们实际上不支持Spring-Cloud-Stream测试支持，而支持Gary提到的新测试绑定。我刚才提供的链接中记录了这样做的原因，但请随时提出问题。虽然它的用法有很好的文档记录，但这里是我们自己使用它的一个测试用例，供您参考。尽管ref文档中的示例显示了基于函数的消息处理程序，但它与基于注释的消息处理程序（您正在使用）的工作方式相同。

谈到基于注释的编程模型，请参阅我们刚刚发布的以下博客（在工作中可以查看更多），其中我们阐述了为什么我们要放弃基于注释的编程模型，我认为您也应该开始考虑更改代码。毕竟，所有的更改都相当于删除所有注释，并稍微更改消息处理程序方法的签名，以表示为函数bean

• https://spring.io/blog/2019/10/14/spring-cloud-stream-demystified-and-simplified
• https://spring.io/blog/2019/10/17/spring-cloud-stream-functional-and-reactive
• https://spring.io/blog/2019/10/25/spring-cloud-stream-and-spring-integration

我说这些的原因很多，但您上面的代码和您表达的担忧再次提醒我，为什么我们要远离这种编程模型。

我将在这里停下来，因为我相信这里有很多东西需要消化，但鉴于我刚才所说的内容，请随时提出更尖锐的问题。