在启用secondLevelRetriesEnabled时，如何对Rebus处理程序进行单元测试IFailed<Message>处理

Question

我正在为我的Rebus处理程序编写一些单元测试。我选择了启用secondLevelRetriesEnabled，这会导致在处理程序中抛出异常时发布IFailed<TMessage>。

我的Handler类定义是：

Handler<T> : IHandleMessages<T>, IHandleMessages<IFailed<T>>

当我运行这个进程时，一切都像预期的那样工作；当我试图为secondLevelRetriesEnabled行为编写单元测试时，困难就来了。

当我的单元测试调用我的处理程序的IFailed<TMessage>方法时，这将导致对await bus.Advanced.TransportMessage.Deadletter(message)的调用，我从FakeBus得到以下异常。

"Attempted to dead-letter the current message using error details 'Failed to handle message after 2 deferrals', but no message context could be found! This is probably a sign that this method was called OUTSIDE of a Rebus handler, or on a separate, disconnected thread somehow. Please only call this method inside Rebus handlers."

在测试IFailed消息句柄时，有人能为我指出解决死信队列异常的正确方向吗？据我所知，没有像SagaFixture那样支持fixture.DeliverFailed(new OrdinaryMessage(...), new ApplicationException("oh no"));的HandleFixture

Answer 1

我不认为目前有一个非常优雅的方法，但有一种方法可以让你自己变得更漂亮，就像这样：

// this is the message we're pretending to be handling
var transportMessage = new TransportMessage(...);

using var scope = new RebusTransactionScope();

var transactionContext = scope.TransactionContext;
var incomingStepContext = new IncomingStepContext(transportMessage, transactionContext);

// fake incoming step context here:
transactionContext.Items[StepContext.StepContextKey] = incomingStepContext;

// now MessageContext.Current should return a proper IMessageContext

//< exercise your handler here

//< check incomingStepContext here

这显然是可以更好的东西，所以可以在Rebus.TestHelpers repository中提出一个问题，这将是解决这个问题的某种解决方案的合适地方。