为依赖ExternalService的MyService类编写单元测试及异常处理咨询

组件说明 #

• IMyService：定义服务方法的接口
• MyService：IMyService的具体实现类，依赖第三方库的ExternalService

public interface IMyService 
{
    Task<MyResult> CreateAsync(string id, string json);
}

internal class MyService : IMyService
{
    private readonly ExternalService _externalService;

    public MyService(ExternalService externalService) 
    {
        this._externalService = externalService;
    }

    public async Task<MyResult> CreateAsync(string id, string json)
    {
        ServiceResult serviceResult = await this._externalService.RunAsync(id, json);

        return new MyResult(serviceResult);
    }
}

MyService的CreateAsync方法接收id和json参数，调用第三方ExternalService.RunAsync，并将返回的ServiceResult转换为自定义的MyResult类。

问题1：如何对MyService.CreateAsync开展单元测试？该方法无业务逻辑，编写单元测试是否有价值？ #

测试方法 #

核心思路是模拟第三方依赖的行为，步骤如下：

1. 使用Mock框架（如Moq）创建ExternalService的模拟实例（注意：如果ExternalService是类，需要确保RunAsync是虚方法或可继承的；如果是接口则直接Mock即可）；
2. 配置模拟实例的RunAsync方法，预设返回指定的ServiceResult，或者模拟抛出异常的场景；
3. 实例化MyService时传入这个模拟实例；
4. 调用CreateAsync方法，验证两点：
   • 返回的MyResult是否正确转换自模拟返回的ServiceResult；
   • ExternalService.RunAsync是否被正确调用（参数匹配、调用次数符合预期）。

测试价值 #

哪怕这个方法只是做“转发+结果转换”，单元测试依然有必要：

• 验证参数传递正确性：确保id和json没有传反、漏传，参数能正确传递给第三方服务；
• 验证结果转换逻辑：确认MyResult能正确承接ServiceResult的所有必要数据，转换逻辑无错误；
• 提前感知依赖变更：如果第三方服务的RunAsync签名、返回结构发生变化，测试会直接失败，及时预警避免影响上层业务；
• 替代低效集成测试：单元测试能快速验证这个“适配层”的正确性，无需每次测试都启动第三方服务，提升测试效率。

问题2：ExternalService执行RunAsync时会抛出自有异常，是否需捕获并封装为自定义异常（如ExternalServiceException转MyServiceException）？ #

建议捕获并封装为自定义异常，原因如下：

1. 解耦上层与第三方依赖：上层业务只需处理你的MyServiceException，不用关心第三方服务的具体异常类型。如果以后替换第三方服务，上层代码无需修改；
2. 统一异常体系：将第三方异常转换成符合项目规范的异常类型，方便全局异常处理、统一日志格式；
3. 补充上下文信息：封装时可以添加业务相关的上下文（比如当前操作的id、业务描述），让日志更易定位问题；
4. 隐藏实现细节：避免上层业务感知到你使用了哪个第三方服务，降低系统耦合度。

若项目极小且确定不会更换第三方服务，也可以暂时不封装，但从长期可维护性来看，封装是更优选择。

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