C# NUnit单元测试中处理邮件附件添加的相关问题咨询

首先要明确两个基础认知：

• 你代码里的emailAttachments.Add(new Attachment(file))操作无法通过常规Mock框架直接模拟：因为Attachment是在方法内部硬编码实例化的具体类，既不是通过依赖注入传入的对象，也没有可重写的成员做拦截，Moq、NSubstitute这类主流Mock工具只能拦截外部传入的接口/虚拟类成员，无法干预方法运行时直接new出来的对象的创建过程。
• 测试运行到该行代码报错的本质原因，不是测试逻辑有问题，是System.Net.Mail.Attachment的构造函数本身就会校验传入路径的文件是否真实存在，路径无效就直接抛异常，这个校验是.NET框架内置的逻辑，和你要测试的邮件发送核心业务没有直接关系。

方案1：测试阶段生成真实临时文件（零业务代码改动，推荐优先使用） #

完全不需要修改生产代码，测试环节不要硬编码不存在的文件路径，直接动态生成真实存在的临时文件即可：

• 借助NUnit内置的TestContext获取测试运行目录，生成带唯一标识的临时文件，避免文件冲突
• 用生成的真实文件路径作为入参调用被测试方法，让Attachment的构造逻辑正常执行
• 测试完成后统一清理临时文件，避免测试目录残留垃圾文件

示例测试代码片段：

[Test]
public void SendEmail_WithValidAttachment_Succeeds()
{
    // 生成测试用真实临时附件
    var tempAttachmentPath = Path.Combine(
        TestContext.CurrentContext.TestDirectory, 
        $"temp_test_{Guid.NewGuid()}.txt");
    File.WriteAllText(tempAttachmentPath, "单元测试临时附件内容");

    // 执行被测试的邮件发送方法，传入真实附件路径
    var sendResult = _emailService.SendTestEmail(attachmentPath: tempAttachmentPath);

    // 执行核心业务断言
    Assert.That(sendResult, Is.True);

    // 清理临时文件
    if (File.Exists(tempAttachmentPath))
        File.Delete(tempAttachmentPath);
}

这种方案的测试行为和生产环境的真实运行逻辑完全一致，没有Mock带来的逻辑偏差，稳定性最高，也是针对文件IO类依赖的通用测试处理方式。

方案2：抽离附件创建的抽象工厂（适合长期维护的业务代码） #

如果不想让测试依赖真实文件资源，可以通过简单的解耦让附件创建逻辑可替换：

• 定义IEmailAttachmentFactory接口，封装附件实例的创建逻辑
• 生产环境下实现接口时，直接调用new Attachment(file)完成真实附件创建
• 通过构造函数把工厂实例注入到邮件服务类中，替换原来内部硬编码的new Attachment(file)逻辑
• 单元测试阶段直接Mock这个工厂接口，返回自定义的、无文件校验逻辑的Attachment实例，完全绕开文件存在性的校验

注意：不建议强行直接MockSystem.Net.Mail.Attachment类本身，这个类没有无参构造函数，内部的文件流处理逻辑也不适合被替换，抽工厂是最干净的解耦方式。

方案3：暴露附件列表的创建入口（轻量重构方案） #

如果不想引入额外的接口依赖，可以把原来硬编码的new List<Attachment>()逻辑抽成类的受保护虚方法：

• 把内部创建附件列表的逻辑改成可在子类重写的虚方法
• 写测试的时候，创建一个继承自邮件服务类的测试子类，重写这个虚方法，返回你自定义的可追踪附件列表
• 这样既可以拦截Add操作的执行，也不需要依赖真实文件，改动成本比引入接口更低

不要为了绕开文件不存在的报错，去修改生产代码跳过Attachment的构造函数校验逻辑——这个文件校验本身就是框架提供的生产环境保护能力，本来就应该拦截无效的附件路径，测试只要保证传入的测试路径合法，就符合业务预期，不需要绕过框架本身的校验。

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