无公共构造函数时如何为Directory Services扩展方法编写单元测试

本次用于Directory Services的实用扩展方法代码如下，功能为将NT域与用户ID字段拼接为标准身份标识后，传入后续处理流程：

public static IEnumerable<string> NtUserIds(this ResultPropertyCollection coll)
{        
    var domains = coll[ntDomain].Cast<string>();
    var ids = coll[ntUserID].Cast<string>();
    return domains.Zip(ids, (domain, id) => $"{domain}\\{id}");
}

当前测试环节的具体卡点：

• ResultPropertyCollection未提供公共构造函数，无法直接创建实例传入测试流程
• 尝试使用Moq做依赖模拟时，发现该类索引器返回的ResultPropertyValueCollection同样没有公共构造函数，无法完成测试场景的配置

两个类虽未开放公共构造函数，但并非完全无法实例化，可根据实际测试需求选择以下路径推进：

• 路径1：通过反射调用内部构造函数生成测试实例
  ResultPropertyValueCollection内置了接收object[]类型参数的内部构造函数，传入预设的属性值数组即可生成对应的值集合。准备好NT域、用户ID两组测试值集合后，再通过反射调用ResultPropertyCollection的内部构造函数，将两个键和对应的值集合作为字典传入，即可得到完整的测试用属性集合。反射调用时需要匹配BindingFlags.NonPublic | BindingFlags.Instance标记，否则无法定位到非公共构造函数。
• 路径2：轻量抽象解耦，降低框架类依赖
  如果不想维护反射逻辑，可以为扩展方法的核心依赖定义最小抽象：只暴露按键获取字符串序列的能力，将原有的拼接逻辑从直接依赖ResultPropertyCollection，调整为面向该抽象接口实现。生产环境下只需写一层极薄的适配代码，将ResultPropertyCollection的实际逻辑映射到抽象接口上，测试时直接模拟该抽象接口即可，完全无需处理不可构造的框架类。
• 路径3：复用社区封装的测试辅助工具
  针对Directory Services中这类不可构造的框架类，社区已有成熟的封装工具，直接传入测试用的键值对即可生成可用的集合实例，不需要重复编写反射逻辑。

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