如何用C#、xUnit、NSubstitute为含内部构造函数的BlobItem创建测试替身？

方案1：使用官方测试辅助类 #

Azure.Storage.Blobs库提供了专门的测试工具包Azure.Storage.Blobs.Testing，里面的BlobItemBuilder可以直接构建合法的BlobItem实例，完全绕开内部构造函数的限制：

// 先安装NuGet包：Azure.Storage.Blobs.Testing
var testBlob = new BlobItemBuilder()
    .WithName("sample-blob.pdf")
    .WithProperties(new BlobPropertiesBuilder().Build())
    .Build();

这是官方推荐的测试方案，无需自己实现反射或其他hack逻辑。

方案2：封装业务模型隔离SDK依赖 #

把业务逻辑依赖的Blob核心属性（比如Name）封装成自定义的业务模型，在业务代码中先将BlobItem转换为自定义模型，后续逻辑只依赖自定义模型：

// 自定义业务模型
public class BlobInfo
{
    public string Name { get; set; }
    // 按需添加其他业务需要的属性
}

// 业务代码中的转换逻辑
var blobList = _containerClient.GetBlobs()
    .Select(b => new BlobInfo { Name = b.Name })
    .ToList();
// 后续业务逻辑仅操作BlobInfo列表

这种方式从架构层面解耦了Azure SDK依赖，测试时直接模拟自定义模型即可，完全不用处理BlobItem的限制，同时提升代码的可维护性。

方案3：封装反射工具方法（临时过渡） #

如果暂时不想引入测试包或修改架构，可以把反射逻辑封装成一个静态工具类，避免重复代码导致混乱：

public static class BlobTestUtils
{
    public static BlobItem CreateTestBlobItem(string blobName)
    {
        var constructor = typeof(BlobItem).GetConstructor(
            BindingFlags.Instance | BindingFlags.NonPublic,
            new[] { typeof(string), typeof(BlobProperties), typeof(IDictionary<string, string>) });
        return (BlobItem)constructor.Invoke(new object[] { blobName, new BlobProperties(), null });
    }
}

测试时直接调用BlobTestUtils.CreateTestBlobItem("test-file.txt")生成实例，把反射逻辑集中管理。

方案4：向Azure SDK团队反馈优化建议 #

如果认为当前SDK的设计确实影响测试便利性，可以去Azure SDK的GitHub仓库提交Feature Request，说明单元测试中需要构造BlobItem的场景，请求开放更友好的测试入口。不过这个方案周期较长，适合长期优化。

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