Azure Function（变更源触发器）单元测试方法及示例咨询

针对你想给带有Change Feed Trigger的Azure Function写单元测试的需求，我来拆解下两种可行的方案，以及对应的示例：

方案一：直接调用函数方法（单元测试首选） #

直接调用FunctionClass.Run(documents, null);这种方式其实是单元测试的最优解，因为单元测试的核心就是隔离外部依赖，只聚焦函数本身的业务逻辑。Change Feed Trigger是Azure提供的外部触发机制，单元测试阶段完全不需要真的去触发它——我们只需要构造好模拟的输入参数，直接调用函数的业务逻辑部分，就能验证逻辑是否正确。

举个C#的实际示例：
假设你的函数类是这样的（用构造函数注入依赖，方便测试时替换为模拟实现）：

public class ChangeFeedProcessorFunction
{
    private readonly IDocumentProcessor _processor;

    public ChangeFeedProcessorFunction(IDocumentProcessor processor)
    {
        _processor = processor;
    }

    [FunctionName("ChangeFeedProcessor")]
    public async Task Run(
        [CosmosDBTrigger(
            databaseName: "InventoryDB",
            collectionName: "Products",
            ConnectionStringSetting = "CosmosDBConnection",
            LeaseCollectionName = "leases")] IReadOnlyList<Document> inputDocs,
        ILogger log)
    {
        if (inputDocs?.Count > 0)
        {
            log.LogInformation($"Received {inputDocs.Count} documents to process");
            foreach (var doc in inputDocs)
            {
                await _processor.Process(doc);
            }
        }
    }
}

对应的单元测试可以用xUnit + Moq来写，轻松模拟依赖和输入：

public class ChangeFeedProcessorFunctionTests
{
    [Fact]
    public async Task Run_WithValidDocuments_CallsProcessorForEach()
    {
        // 1. 模拟依赖服务和日志
        var mockProcessor = new Mock<IDocumentProcessor>();
        var mockLogger = new Mock<ILogger>();

        // 2. 构造测试用的文档列表
        var testDocs = new List<Document>
        {
            new Document { Id = "prod-1", PartitionKey = "electronics" },
            new Document { Id = "prod-2", PartitionKey = "clothing" }
        };

        // 3. 实例化函数并执行
        var function = new ChangeFeedProcessorFunction(mockProcessor.Object);
        await function.Run(testDocs, mockLogger.Object);

        // 4. 验证逻辑是否符合预期：每个文档都被处理了
        mockProcessor.Verify(p => p.Process(It.IsAny<Document>()), Times.Exactly(2));
    }

    [Fact]
    public async Task Run_WithEmptyDocuments_DoesNothing()
    {
        var mockProcessor = new Mock<IDocumentProcessor>();
        var mockLogger = new Mock<ILogger>();

        var function = new ChangeFeedProcessorFunction(mockProcessor.Object);
        await function.Run(new List<Document>(), mockLogger.Object);

        // 验证处理器没有被调用
        mockProcessor.Verify(p => p.Process(It.IsAny<Document>()), Times.Never);
    }
}

这种方式的优势很明显：

• 测试运行速度极快，不需要启动任何外部服务
• 能精准覆盖各种边界场景（空输入、单文档、异常文档等）
• 可以清晰验证函数对依赖服务的调用是否符合预期

方案二：使用Cosmos DB模拟器（适合集成测试） #

如果你想验证端到端的触发流程（比如确认Function能正确响应Cosmos DB的Change Feed），那可以用Cosmos DB模拟器，但这更属于集成测试的范畴，而非单元测试——因为它需要依赖外部服务的交互。

简单的实现思路是：

• 启动本地Cosmos DB模拟器（可以通过Docker容器或者本地安装的客户端）
• 把Function的连接字符串配置指向模拟器的地址
• 在测试中往模拟器的目标集合插入文档
• 验证Function是否正确捕获并处理了这些文档

不过这种方式比较重，启动模拟器需要时间，测试也会更慢，适合在单元测试通过后，用来验证整体流程的正确性。

总结 #

• 单元测试阶段：优先选择直接调用函数方法，聚焦内部逻辑验证
• 集成测试阶段：可以用Cosmos DB模拟器验证完整触发流程

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