如何测试MassTransit Saga状态机中Fault<T>触发的事件？

一、测试消费者抛错触发Saga的正确姿势 #

直接发布Fault<CreateAgreementMessage>无效，因为MassTransit的Fault消息是框架在消费者抛出未捕获异常时自动生成并发布的，手动发布的消息不符合框架格式，无法被Saga识别。正确做法是让测试中的消费者实际抛出异常，触发框架生成合规的Fault消息，进而被Saga处理：

1. 用ConsumerTestHarness<CreateAgreementConsumer>注册你的消费者，通过测试桩或依赖注入让消费者在处理CreateAgreementMessage时抛出异常
2. 发布CreateAgreementMessage到TestHarness，等待框架自动生成Fault消息并被Saga消费
3. 验证Saga的状态变化（失败数更新、进入Done状态等）

示例代码（C#）：

// 初始化测试 harness
var harness = new InMemoryTestHarness();
var sagaHarness = harness.Saga<YourSagaStateMachine, YourSagaState>();

// 注册消费者，模拟处理时抛错
harness.Consumer(() => new CreateAgreementConsumer { ShouldThrow = true });

await harness.Start();
try
{
    var sagaId = Guid.NewGuid();
    // 先将Saga推进到Processing状态（根据你的业务逻辑调整）
    await harness.Publish(new StartProcessingMessage { SagaId = sagaId, TotalDocuments = 1 });

    // 发布触发异常的消息
    await harness.Publish(new CreateAgreementMessage { SagaId = sagaId });

    // 验证Saga状态
    var saga = sagaHarness.Created.Single(x => x.CorrelationId == sagaId);
    saga.CurrentState.ShouldBe(YourSagaStateMachine.Done);
    saga.FailedDocuments.ShouldBe(1);
}
finally
{
    await harness.Stop();
}

如果你的Saga是处理自定义的CreateAgreementFaulted事件而非框架生成的Fault<>，则需要修改消费者，在捕获异常后主动发布该自定义事件：

public class CreateAgreementConsumer : IConsumer<CreateAgreementMessage>
{
    private readonly IPublishEndpoint _publishEndpoint;

    public CreateAgreementConsumer(IPublishEndpoint publishEndpoint)
    {
        _publishEndpoint = publishEndpoint;
    }

    public async Task Consume(ConsumeContext<CreateAgreementMessage> context)
    {
        try
        {
            // 业务逻辑：尝试创建文档
            throw new InvalidOperationException("文档创建失败");
        }
        catch (Exception ex)
        {
            // 发布自定义失败事件
            await _publishEndpoint.Publish(new CreateAgreementFaulted
            {
                SagaId = context.Message.SagaId,
                FailureReason = ex.Message
            });
            // 如需框架处理重试/死信，可选择重新抛出异常
            // throw;
        }
    }
}

这种场景下，测试时也可以直接模拟发布CreateAgreementFaulted事件，快速验证Saga的处理逻辑。

二、自定义失败消息vs抛出异常的选型建议 #

两种方式各有适用场景，可根据业务需求选择：

• 选择抛出异常：
  • 适合需要利用MassTransit内置错误机制（重试、死信队列、错误监控）的场景
  • 框架自动生成的Fault消息包含完整错误细节（堆栈跟踪、异常类型），便于问题排查
  • 无需额外定义业务事件，减少代码量
• 选择自定义失败消息：
  • 适合业务层只需传递失败状态和关键业务信息（无需技术细节）的场景
  • 事件语义更清晰（如CreateAgreementFaulted直接对应业务失败动作）
  • 可自定义字段（如失败原因码、关联业务ID），更贴合业务逻辑

如果Saga仅需感知“创建失败”的结果，自定义失败消息更合适；若需保留错误详情或依赖框架错误处理能力，抛出异常让框架生成Fault更便捷。

内容的提问来源于stack exchange，提问作者Jonas Peterson