MassTransit跨服务请求收发测试异常：请求达消费者但无响应

你遇到的核心问题是测试代码中测试Harness与实际发送请求的Mediator/总线实例不匹配，导致请求虽然能到达消费者，但测试环境无法捕获响应。以下是具体问题点和修复方案：

问题1：测试类与基类的服务容器完全隔离 #

你的测试类UnbindVisilibityTests在Init方法中新建了独立的ServiceProvider和TestHarness，但测试时调用的Mediator来自基类InfrastructureDataTestBase初始化的实例——这个Mediator绑定的是真实RabbitMQ总线，而非测试Harness的总线。两者属于不同服务容器，测试Harness根本没收到发送的请求，自然无法返回响应。

修复方案：
放弃在测试类中单独创建ServiceProvider，直接复用基类的服务容器获取TestHarness：

[TestInitialize]
public void Init()
{
    // 直接从基类的serviceProvider获取测试Harness
    _harness = serviceProvider.GetRequiredService<ITestHarness>();

    idVis = _infrastructureDal.InsertVisibility("UnbindVisibilityCommandTest", "TestAppl");

    command = new UnbindVisibilityCommand
    {
        Id = idVis,
    };
}

问题2：基类中MassTransit配置混淆测试与生产环境 #

基类的GetServiceProvider中同时配置了真实RabbitMQ连接和AddMassTransitTestHarness，导致测试环境仍连接真实MQ，无法实现隔离测试。测试时应使用内存总线替代真实RabbitMQ。

修复方案：
添加测试环境判断，区分配置逻辑：

// 通过配置或标记判断是否为测试环境，示例中直接设为true，实际可从配置读取
bool isTestEnvironment = true;

services.AddMassTransit(x =>
{
    x.AddConsumer<UnbindUsersFromVisibilityFilterRequestConsumer>();

    if (isTestEnvironment)
    {
        // 测试环境：内存总线+TestHarness
        x.AddMassTransitTestHarness(testCfg =>
        {
            testCfg.AddDelayedMessageScheduler();
            testCfg.AddConsumer<UnbindUsersFromVisibilityFilterRequestConsumer>();
        });

        x.UsingInMemory((context, cfg) =>
        {
            cfg.ConfigureEndpoints(context);
        });
    }
    else
    {
        // 生产环境：真实RabbitMQ配置
        x.UsingRabbitMq((context, cfg) =>
        {
            cfg.Host(messageBrokerOptions.HostName, (ushort)messageBrokerOptions.Port, messageBrokerOptions.VirtualHost, h =>
            {
                var rsaFile = config.GetValue<string>("RsaKeyFullFilePath");

                var cryptoService = string.IsNullOrWhiteSpace(rsaFile)
                    ? Digitronica.IT.Infrastructure.Security.Cryptography.CryptoService.CreateDefault()
                    : Digitronica.IT.Infrastructure.Security.Cryptography.CryptoService.CreateFromXmlFile(rsaFile);

                h.Username(messageBrokerOptions.Username);
                h.Password(cryptoService.Decrypt(messageBrokerOptions.Password));
            });

            cfg.ConfigureEndpoints(context);
        });
    }

    x.AddRequestClient<IUnbindUsersFromVisibilityFilterRequest>();
});

问题3：同步调用引发死锁风险 #

测试方法中使用Mediator.Send(command).Result同步等待异步操作，容易引发死锁，尤其在测试环境中。

修复方案：
改为异步等待：

[TestMethod]
public async Task Unbind_OK()
{
    await _harness.Start();

    var result = await Mediator.Send(command);

    Assert.IsTrue(result is SuccessCommandResult);

    await _harness.Stop();
}

额外验证点 #

1. 确认UnbindVisibilityCommand是否实现了IUnbindUsersFromVisibilityFilterRequest接口，否则Mediator无法将其路由到对应消费者。
2. 检查消费者的RespondAsync是否返回了与请求匹配的响应类型，确保IUnbindUsersFromVisibilityFilterResult与Mediator期望的返回类型一致。
3. 可在测试中添加断言验证请求是否被Harness捕获：

// 发送请求后添加
Assert.IsTrue(await _harness.Consumed.Any<IUnbindUsersFromVisibilityFilterRequest>());

内容的提问来源于stack exchange，提问作者Francesco Vargas