使用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

spring-cloud-stream-test启用了非常基本的测试绑定器；它没有真正的活页夹的所有功能。

Answer 2

@@ Joao Pereira，我认为这里有一个更大的问题，因此，我将尝试进行布局，希望能提供一些清晰度

1. 具有用ServiceActivator注释的错误处理程序方法的能力是框架提供的合同，这意味着其测试是我们的责任。此外，您使用的机制甚至不是来自Spring Cloud Stream，而是来自Spring Integration。但是不管怎么说，我怀疑应用程序是否应该对它进行测试，因为您不能在应用程序级别以任何方式影响它，因为它不是您的功能。同样，这是我的看法，我很想知道您的想法。

2. 使用Spring Cloud Stream 3.0.0.RC1（及后续版本），我们有效地弃用spring-cloud-stream-test-support，而赞成Gary提到的new test binder。我刚刚提供的链接中记录了它的原因，但是请随时提出问题。尽管它的用法已被很好地记录在案，但在one of the test cases中，我们将自己使用它作为参考。并且尽管ref doc中的示例显示了基于函数的消息处理程序，但它与基于注释的消息处理程序（这就是您正在使用的）的工作方式相同。

3. 说到基于注释的编程模型，请参阅以下我们刚刚发布的博客（更多内容正在研究中），我们在其中列出了为何脱离基于注释的编程模型的案例而且我认为您也应该开始考虑更改代码。毕竟，这些更改几乎等于删除所有注释并稍微更改消息处理程序方法的签名以表示为功能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

我之所以这么说的原因很多，但是您上面的代码和您所表达的担忧再次使我想起为什么我们要脱离这种编程模型。

我会在这里停下来，因为我相信这里有很多要消化的地方，但是鉴于我刚才所说的，请随时提出更尖锐的问题。