我已經使用 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 只是定義為字符串常量：@UtilityClasspublic 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 時是否有任何配置、技巧或技巧可以將錯誤消息發送到錯誤通道？
2 回答
鴻蒙傳說
TA貢獻1865條經驗 獲得超7個贊
我認為這里存在一個更大的問題，所以我會嘗試將其闡述出來，希望能夠提供一些清晰的信息
能夠使用 ServiceActivator 注釋錯誤處理程序方法是框架提供的契約，這意味著它的測試是我們的責任。此外，您使用的機制甚至不是來自 Spring Cloud Stream，而是來自 Spring Integration。但無論如何，我質疑應用程序是否應該測試它，因為您無法在應用程序級別以任何方式影響它，因為它不是您的功能。再說一次，這是我的觀點，我很想知道你的想法。
在 Spring Cloud Stream 3.0.0.RC1（及后續版本）中，我們實際上已經棄用了
spring-cloud-stream-test-supportGary提到的新測試綁定器。其原因記錄在我剛剛提供的鏈接中，但請隨時跟進問題。盡管它的用法有相當詳細的記錄，但這里是我們自己使用它的測試用例之一，供您參考。盡管參考文檔中的示例顯示了基于函數的消息處理程序，但它的工作方式與基于注釋的消息處理程序（這就是您正在使用的）相同。說到基于注釋的編程模型，請參閱我們剛剛發布的以下博客（查找更多內容，因為它們正在工作中），其中我們闡述了為什么我們要放棄基于注釋的編程模型，我認為您也應該開始考慮更改您的代碼。畢竟，所有更改幾乎相當于刪除所有注釋并稍微更改消息處理程序方法的簽名以表示為函數 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
我之所以這么說的原因有很多，但是您上面的代碼和您表達的擔憂再次提醒我為什么我們要放棄這種編程模型。
我將在這里停下來，因為我相信這里有很多東西需要消化，但鑒于我剛才所說的內容，請隨意跟進更尖銳的問題。
添加回答
舉報
0/150
提交
取消