Integration Testing Azure Durable Function

[theplankmeister]

I have an application that uses Azure Durable Functions in which an orchestration is triggered by a ServiceBusTrigger. The class in which this happens has an instance of IDurableClient injected by DI. When I run the application locally in VS2022, everything works as expected, also when it's deployed to Azure.

I followed the instructions at https://techcommunity.microsoft.com/t5/fasttrack-for-azure/azure-functions-part-2-unit-and-integration-testing/ba-p/3769764#toc-hId-88794323 that clearly and concisely instruct on how to perform integration tests in the context of Azure Functions. Following this, I was able to successfully write integration tests for all the HttpTrigger-ed functions. These tested functions consume many different services from the DI container (APIs, databases, storage, etc), and it all works as expected.

However, when specifically attempting to perform integration testing of a durable function, it is not behaving as expected. As with the integration tests against the HttpTrigger-ed functions, an instance of the class containing the functions to be tested is obtained through DI in the test case constructor. To facilitate testing without having to mock service bus infrastructure, it contains the following methods:

    [FunctionName(nameof(SendNotificationListener))]
    [Singleton(Mode = SingletonMode.Listener)]
    public async Task SendNotificationListener(
        [ServiceBusTrigger(SEND_NOTIFICATION_QUEUE_NAME, Connection = "SBCon")] ServiceBusReceivedMessage msg
    ) {
        await StartOrchestration(msg.Body);
    }

    public async Task<string> StartOrchestration(
        BinaryData payload
    ) {
        return await _durableClient.StartNewAsync(orchestratorFunctionName: nameof(MainOrchestrator), input: payload.ToString());
    }

This allows me to invoke StartOrchestration() from the test case and get the returned instance ID. The problem is, the orchestration doesn't actually start. When invoking through the ServiceBusTrigger-ed function, the orchestrator (MainOrchestrator) is started, as expected. But when invoking StartOrchestration() from the test case (with an appropriate payload that is 100% identical to that obtained from the body of the ServiceBusReceivedMessage in SendNotificationListener()) the MainOrchestrator is not instantiated. When I inspect the task hub tables in table storage, I can see that a new instance is inserted into the Instances table. But the orchestrator itself is not triggered.

Is there something I'm overlooking? I've even compared the registered services in the ServiceCollection between the Startup and TestStartup classes in an effort to see any services that might be missing, but there is nothing that stands out, even though there are a lot of differences between the registered services. Is it perhaps because, fundamentally, because of the way the asynchronous behaviour is implemented, that it's just not even possible? Am I barking up the wrong tree?

[theplankmeister]

After many days of frustration, I found the answer. I found it in the AzureFunctions.TestHelpers project. Basically, the only thing I was missing, was a single (but important) line of code. In my integration test fixture class, there where I configure my HostBuilder, all I needed to do was invoke:

hostBuilder = new HostBuilder()
    .ConfigureWebJobs(...)
    ... // More configuration goes here
    .Build();

await hostBuilder.StartAsync(); // This is the magic line.

...and that was it, it started working. Along with the other IJobHost extension methods provided by AzureFunctions.TestHelpers to properly manage the jobs, everything works as expected, which means I can run completely encapsulated integration tests of whole orchestrations and their activities. Which is very nice indeed.