C#含单元测试的组合方法：如何测试HandleRequests的if代码块？

你说得太对了——单纯mock三个依赖，然后验证它们有没有被调用，这种测试完全是盯着代码实现细节看，脆弱得不行。哪天你把方法调用顺序调一下，或者把某个服务的实现换了，测试直接炸，但实际功能说不定一点问题都没有。真正靠谱的测试，得盯着业务结果，而不是内部调用那点事儿。

下面给你拆解几个实用的思路：

1. 按业务场景拆测试用例 #

咱们先抓核心：这段代码是处理IsDelete = true的请求，依次做日期检查、发通知、创建发票。那测试就围绕这几个业务动作的结果来：

场景1：验证已删除请求的日期检查逻辑 #

• 造一个IsDelete = true但日期不符合要求的请求（比如过期的、或者还没到处理时间的）
• 调用HandleRequests
• 看日期检查的实际结果：比如是不是抛出了特定异常？或者请求的状态被标记成“检查不通过”了？（具体要看CheckRequest的业务逻辑）
• 别纠结CheckRequest有没有被调用，要看它执行后带来的业务影响

场景2：验证通知是否发对了 #

• 造一个IsDelete = true且能通过日期检查的请求
• 调用HandleRequests
• 查通知的内容和接收方对不对：比如看通知里有没有包含请求ID、是不是标记了“删除相关”的标识；如果通知存在数据库或者消息队列里，直接查这些存储的内容就行，不用mock调用

场景3：验证发票是否正确生成 #

• 同样用符合条件的请求（IsDelete = true+通过日期检查）
• 调用HandleRequests
• 看发票的属性匹配不匹配：比如发票关联的请求ID对不对、金额是不是符合规则、状态是不是正确，有没有出现在数据库里
• 还是那句话，直接看最终生成的实体，别盯着方法调用

2. 用集成测试补全单元测试的缺口 #

如果这三个服务之间有依赖（比如创建发票得等通知发完？或者日期检查的结果会影响发票内容），单独的单元测试可能覆盖不全。这时候可以写个轻量级集成测试：

• 用真实的服务实现（或者内存版的依赖，比如内存数据库），别全用mock
• 造符合条件的请求，跑HandleRequests
• 端到端验证整个流程：日期检查过了、通知发出去了、发票也生成了，而且所有信息都对

3. 重构代码让测试更顺手（可选但推荐） #

要是这段代码现在测试起来费劲，可以先重构一下，把if块里的逻辑抽成单独的方法：

public void HandleRequests() 
{ 
    var requests = _requestService.GetAll(); 
    foreach(var request in requests) 
    { 
        if (request.IsDelete) 
        { 
            ProcessDeletedRequest(request);
        } 
    } 
}

// 抽出来的方法，单独测更方便
private void ProcessDeletedRequest(Request request)
{
    _dateCheckerService.CheckRequest(request); 
    _notificationService.Send(request); 
    _invoiceService.CreateInvoice(request); 
}

这样你可以单独测ProcessDeletedRequest，但核心还是要盯着业务结果，别跑偏到验证方法调用上。

最后再啰嗦一句：测试的目的是确保业务需求被满足，不是确保代码和你写的时候一模一样。盯着结果测，你的测试会更稳、更有用。

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