如何用NUnit和Moq测试含密封参数的C# IExpressionEditorService方法？

针对你遇到的AssemblyContextControlItem和ImportedNamespaceContextItem这类密封类无法Mock的问题，这里有几个实用思路帮你完成单元测试：

1. 直接创建密封类实例并手动配置属性 #

虽然这两个类是密封的，但它们提供了公共属性或构造函数来初始化核心数据，完全不需要依赖完整的工作流设计器实例。你可以直接创建实例，然后设置测试所需的最小配置：

// 配置AssemblyContextControlItem
var assemblyContext = new AssemblyContextControlItem();
// 添加测试需要的程序集
assemblyContext.Assemblies.Add(typeof(string).Assembly);
assemblyContext.LocalAssembly = typeof(YourTestType).Assembly;

// 配置ImportedNamespaceContextItem
var importedNamespaces = new ImportedNamespaceContextItem();
// 添加测试需要的命名空间
importedNamespaces.ImportedNamespaces.Add("System");
importedNamespaces.ImportedNamespaces.Add("System.Collections.Generic");

// 准备其他测试参数
var variables = new List<ModelItem>(); // 可按需添加Mock的ModelItem实例
var testExpressionText = "x * 2";
var expressionType = typeof(int);

// 调用要测试的方法
var editorInstance = yourExpressionEditorService.CreateExpressionEditor(
    assemblyContext, 
    importedNamespaces, 
    variables, 
    testExpressionText, 
    expressionType);

// 后续断言验证
Assert.IsNotNull(editorInstance);
// ...添加其他业务逻辑验证

这种方法简单直接，不需要修改现有代码，只要你能明确测试所需的上下文数据，就能快速构造出符合要求的实例。

2. 封装抽象层隔离密封类依赖 #

如果直接构造实例还是觉得耦合度太高，或者需要更灵活的测试隔离，可以定义抽象接口来封装密封类的核心功能，让你的实现类依赖这个抽象接口而非原始密封类：

首先定义抽象接口：

public interface IExpressionEditorContext
{
    IEnumerable<Assembly> GetReferencedAssemblies();
    IEnumerable<string> GetImportedNamespaces();
    // 按需添加其他需要的上下文方法
}

然后实现接口来包装密封类：

public class DefaultExpressionEditorContext : IExpressionEditorContext
{
    private readonly AssemblyContextControlItem _assemblyContext;
    private readonly ImportedNamespaceContextItem _namespaceContext;

    public DefaultExpressionEditorContext(
        AssemblyContextControlItem assemblyContext, 
        ImportedNamespaceContextItem namespaceContext)
    {
        _assemblyContext = assemblyContext;
        _namespaceContext = namespaceContext;
    }

    public IEnumerable<Assembly> GetReferencedAssemblies()
    {
        return _assemblyContext.Assemblies.Append(_assemblyContext.LocalAssembly);
    }

    public IEnumerable<string> GetImportedNamespaces()
    {
        return _namespaceContext.ImportedNamespaces;
    }
}

修改你的IExpressionEditorService实现类，让它内部通过IExpressionEditorContext处理上下文逻辑（如果接口要求必须接收密封类参数，也可以在方法内部将密封类转换为抽象接口实例）。这样测试时就能用Moq轻松Mock抽象接口：

// Mock抽象接口
var mockContext = new Mock<IExpressionEditorContext>();
mockContext.Setup(c => c.GetReferencedAssemblies())
           .Returns(new[] { typeof(string).Assembly });
mockContext.Setup(c => c.GetImportedNamespaces())
           .Returns(new[] { "System" });

// 注入到服务实现中
var yourService = new YourExpressionEditorService(mockContext.Object);

// 执行测试逻辑...

这个方案需要一定代码重构，但能从根本上隔离密封类依赖，让测试更灵活，适合长期维护的项目。

3. 反射设置内部属性（备选方案） #

如果密封类的关键属性没有公共setter，或者需要设置内部字段，可以通过反射强制修改值。不过这种方法依赖类的内部实现细节，可能随框架版本更新失效，只建议作为最后备选：

var assemblyContext = new AssemblyContextControlItem();
// 通过反射获取内部字段并设置值
var assembliesField = typeof(AssemblyContextControlItem)
    .GetField("_assemblies", BindingFlags.Instance | BindingFlags.NonPublic);
assembliesField?.SetValue(assemblyContext, new HashSet<Assembly> { typeof(int).Assembly });

总结 #

优先尝试第一种方法，直接构造密封类实例并配置必要数据——这是最快捷且低侵入的方式；如果需要更彻底的测试隔离，再考虑第二种抽象封装方案；反射只在极端情况下使用。

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