Testing Azure Functions: Unit, Integration, and Local

Azure Functions for .NET Developers: Series

• Part 1: Why Azure Functions? Serverless for .NET Developers
• Part 2: Your First Azure Function: HTTP Triggers Step-by-Step
• Part 3: Beyond HTTP: Timer, Queue, and Blob Triggers
• Part 4: Local Development Setup: Tools, Debugging, and Hot Reload
• Part 5: Understanding the Isolated Worker Model
• Part 6: Configuration Done Right: Settings, Secrets, and Key Vault
• Part 7: Testing Azure Functions: Unit, Integration, and Local ← you are here
• Part 8: Deploying to Azure: CI/CD with GitHub Actions (coming next week)

---

Where do you draw the line between what needs a full Azure connection and what can be tested with a plain class instantiation? The isolated worker model makes the answer concrete: the function class is just wiring. Everything testable lives in a service class that knows nothing about Azure.

Most testing pain comes from not drawing that line early enough.

The design decision that makes testing possible

Consider a function that does its own work:

public class OrderFunction(ILogger<OrderFunction> logger, SqlConnection db)
{
    [Function("CreateOrder")]
    public async Task<IActionResult> CreateOrder(
        [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "orders")] HttpRequest req,
        [FromBody] CreateOrderRequest order)
    {
        if (order.Quantity <= 0)
            return new BadRequestObjectResult("Quantity must be greater than zero");

        var orderId = "ORD-" + Guid.NewGuid().ToString("N")[..8];

        await db.ExecuteAsync(
            "INSERT INTO Orders (OrderId, ProductId, Quantity) VALUES (@OrderId, @ProductId, @Quantity)",
            new { orderId, order.ProductId, order.Quantity });

        logger.LogInformation("Created order {OrderId}", orderId);
        return new CreatedResult($"/orders/{orderId}", new { orderId, order.ProductId, order.Quantity });
    }
}

To unit test this, you need a real SqlConnection. That means a real database, which means either a running SQL Server, Testcontainers, or a brittle in-memory substitute. Every test becomes an infrastructure test, even for something as simple as verifying that a zero quantity returns 400.

The fix is to move the logic into a service class, leaving the function with nothing to do except call the service and map the result to a response:

public class OrderFunction(IOrderService orderService)
{
    [Function("CreateOrder")]
    public async Task<IActionResult> CreateOrder(
        [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "orders")] HttpRequest req,
        [FromBody] CreateOrderRequest order)
    {
        var result = await orderService.CreateOrderAsync(order);

        if (!result.IsSuccess)
            return new BadRequestObjectResult(result.Error);

        return new CreatedResult($"/orders/{result.Order!.OrderId}", result.Order);
    }
}

The function class is now three lines of routing logic. IOrderService is a plain interface with no Azure types, no infrastructure, nothing that requires a running host to instantiate.

This gives you two separate test targets. The service holds the logic and gets fast, isolated unit tests with no framework setup. The function class holds the routing and gets a thin layer of tests that verify the HTTP response shapes. Each layer can be tested on its own terms.

Unit testing the service layer

The service has one dependency worth injecting for tests: IOrderRepository. Here's the full service:

public class OrderService(ILogger<OrderService> logger, IOrderRepository repository) : IOrderService
{
    public async Task<OrderResult> CreateOrderAsync(CreateOrderRequest request)
    {
        if (request.Quantity <= 0)
            return OrderResult.Failure("Quantity must be greater than zero");

        var order = new Order(
            OrderId: "ORD-" + Guid.NewGuid().ToString("N")[..8],
            ProductId: request.ProductId,
            Quantity: request.Quantity);

        await repository.SaveAsync(order);

        logger.LogInformation("Created order {OrderId} for {ProductId}", order.OrderId, order.ProductId);

        return OrderResult.Success(order);
    }
}

To test it, you need xUnit and NSubstitute. The .csproj is minimal:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <IsTestProject>true</IsTestProject>
    <!-- Test method names use underscores by convention (MethodName_Condition_Expected) -->
    <NoWarn>$(NoWarn);CA1707</NoWarn>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" />
    <PackageReference Include="NSubstitute" />
    <PackageReference Include="xunit" />
    <PackageReference Include="xunit.runner.visualstudio">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
    </PackageReference>
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="../HttpTriggerDemo/HttpTriggerDemo.csproj" />
  </ItemGroup>
</Project>

The tests themselves need no Azure infrastructure:

public class OrderServiceTests
{
    private readonly IOrderRepository _repository = Substitute.For<IOrderRepository>();
    private readonly OrderService _service;

    public OrderServiceTests()
    {
        _service = new OrderService(NullLogger<OrderService>.Instance, _repository);
    }

    [Fact]
    public async Task CreateOrderAsync_WithValidRequest_ReturnsSuccess()
    {
        var request = new CreateOrderRequest("WIDGET-42", 3);

        var result = await _service.CreateOrderAsync(request);

        Assert.True(result.IsSuccess);
        Assert.NotNull(result.Order);
        Assert.Equal("WIDGET-42", result.Order.ProductId);
        Assert.Equal(3, result.Order.Quantity);
    }

    [Fact]
    public async Task CreateOrderAsync_WithValidRequest_SavesOrderToRepository()
    {
        var request = new CreateOrderRequest("WIDGET-42", 3);

        await _service.CreateOrderAsync(request);

        await _repository.Received(1).SaveAsync(Arg.Is<Order>(o =>
            o.ProductId == "WIDGET-42" && o.Quantity == 3));
    }

    [Theory]
    [InlineData(0)]
    [InlineData(-1)]
    [InlineData(-100)]
    public async Task CreateOrderAsync_WithInvalidQuantity_ReturnsFailure(int quantity)
    {
        var request = new CreateOrderRequest("WIDGET-42", quantity);

        var result = await _service.CreateOrderAsync(request);

        Assert.False(result.IsSuccess);
        Assert.NotNull(result.Error);
    }

    [Theory]
    [InlineData(0)]
    [InlineData(-1)]
    public async Task CreateOrderAsync_WithInvalidQuantity_DoesNotCallRepository(int quantity)
    {
        var request = new CreateOrderRequest("WIDGET-42", quantity);

        await _service.CreateOrderAsync(request);

        await _repository.DidNotReceive().SaveAsync(Arg.Any<Order>());
    }
}

NullLogger<T>.Instance is the right choice for service tests. You are testing behavior, not logging output. Using Substitute.For<ILogger<T>>() to verify that specific log messages were emitted is a fragile approach: log messages are implementation details that change often and aren't part of the service contract. Save NSubstitute for dependencies whose behavior actually matters to the test outcome, like IOrderRepository.

[Theory] + [InlineData] handles the validation branches without duplicating test body. Each InlineData value runs as a separate test in the output, so you get clear signal on exactly which inputs fail. The two [Theory] blocks above run 3 + 2 = 5 test cases from a handful of lines.

Received() and DidNotReceive() are NSubstitute's call-count assertions. The second [Fact] verifies the repository was called with the right data; the second [Theory] verifies it was never called when validation fails. Together they cover both the happy path and the guard clause.

Unit testing the function class

When you use ConfigureFunctionsWebApplication() (the ASP.NET Core integration mode), the function's HttpRequest is a standard ASP.NET Core HttpRequest. That means you can construct a DefaultHttpContext in tests and pass context.Request directly to the function method, with no Functions runtime involved:

public class OrderFunctionTests
{
    private readonly IOrderService _orderService = Substitute.For<IOrderService>();
    private readonly OrderFunction _function;

    public OrderFunctionTests()
    {
        _function = new OrderFunction(_orderService);
    }

    [Fact]
    public async Task CreateOrder_WhenServiceSucceeds_Returns201Created()
    {
        var request = new CreateOrderRequest("WIDGET-42", 3);
        var order = new Order("ORD-ABCD1234", "WIDGET-42", 3);
        _orderService.CreateOrderAsync(request).Returns(OrderResult.Success(order));

        var result = await _function.CreateOrder(new DefaultHttpContext().Request, request);

        var created = Assert.IsType<CreatedResult>(result);
        Assert.Equal("/orders/ORD-ABCD1234", created.Location);
        Assert.Equal(order, created.Value);
    }

    [Fact]
    public async Task CreateOrder_WhenServiceFails_Returns400BadRequest()
    {
        var request = new CreateOrderRequest("WIDGET-42", -1);
        _orderService.CreateOrderAsync(request)
            .Returns(OrderResult.Failure("Quantity must be greater than zero"));

        var result = await _function.CreateOrder(new DefaultHttpContext().Request, request);

        var bad = Assert.IsType<BadRequestObjectResult>(result);
        Assert.Equal("Quantity must be greater than zero", bad.Value);
    }
}

Notice what these tests do not cover: the [HttpTrigger] attribute, binding resolution, middleware, or anything the Functions host owns. That's intentional. The function's responsibility is to map a service result to an HTTP response. Two tests cover both outcome branches. Anything beyond that is integration territory.

The [HttpTrigger] and [FromBody] attributes are metadata for the runtime. They don't execute during a direct method call, so there's nothing to test or mock.

Timer triggers

Timer functions follow the same pattern. TimerInfo is a concrete class from the Functions SDK with settable properties, so you construct it directly:

public class CleanupFunctionTests
{
    private readonly CleanupFunction _function =
        new(NullLogger<CleanupFunction>.Instance);

    [Fact]
    public async Task Run_WhenOnSchedule_CompletesWithoutError()
    {
        var timer = new TimerInfo { IsPastDue = false };

        await _function.Run(timer);

        // No exception thrown = the function handled the timer correctly.
        // Timer functions have no return value — the observable outcome is
        // either successful completion or an exception.
    }

    [Fact]
    public async Task Run_WhenPastDue_StillCompletes()
    {
        var timer = new TimerInfo { IsPastDue = true };

        await _function.Run(timer);
    }
}

Timer function tests are often this minimal. The function's behavior on IsPastDue = true is to log a warning; there's no meaningful return value to assert on. What you're verifying is that the function reaches completion without throwing, and that the IsPastDue branch doesn't break anything. If your cleanup function does real work (deleting records, archiving blobs), that work lives in a service and gets tested through the service tests, not through the function.

---

Integration testing with Testcontainers

Unit tests get you 80% of the way. They don't verify that DI registrations are correct, that your database schema matches your queries, or that a real TableClient call actually persists what you think it does. That's two separate problems: the composition root, and the data layer.

Verifying the composition root

The first failure mode is silent: a service registration is missing, and OrderFunction's constructor throws at runtime while every unit test passes. A composition test catches this without Docker:

public class HostIntegrationTests : IAsyncLifetime
{
    private IHost _host = null!;

    public async Task InitializeAsync()
    {
        _host = new HostBuilder()
            .ConfigureFunctionsWebApplication()
            .ConfigureServices(services =>
            {
                // WorkerHostedService opens a gRPC channel to the Functions host.
                // That host doesn't exist in tests — remove it or the build hangs.
                var worker = services.FirstOrDefault(s =>
                    s.ImplementationType?.Name == "WorkerHostedService");
                if (worker is not null)
                    services.Remove(worker);
            })
            .Build();

        await _host.StartAsync();
    }

    [Fact]
    public void IOrderService_ResolvesFromDi()
    {
        var service = _host.Services.GetService<IOrderService>();
        Assert.NotNull(service);
    }

    public async Task DisposeAsync() => await _host.StopAsync();
}

WebApplicationFactory<Program> fails with Azure Functions isolated worker. The model uses gRPC for host-worker communication, and the factory hits a channel URI parsing error when no Functions host is running. The HostBuilder approach mirrors Program.cs exactly, with the gRPC listener stripped. This test doesn't call any function logic; it only verifies the container compiles.

Testing the data layer

InMemoryOrderRepository lets unit tests run fast, but it tells you nothing about whether your actual persistence works. A production implementation using Azure Table Storage looks like this:

public class TableStorageOrderRepository(TableClient tableClient) : IOrderRepository
{
    public async Task SaveAsync(Order order)
    {
        var entity = new TableEntity(order.ProductId, order.OrderId)
        {
            ["Quantity"] = order.Quantity
        };
        await tableClient.AddEntityAsync(entity);
    }
}

The integration test spins up Azurite in Docker via Testcontainers:

public class TableStorageOrderRepositoryTests : IAsyncLifetime
{
    private readonly AzuriteContainer _azurite = new AzuriteBuilder().Build();

    public async Task InitializeAsync() => await _azurite.StartAsync();

    [Fact]
    public async Task SaveAsync_WithValidOrder_PersistsToTableStorage()
    {
        var client = new TableClient(_azurite.GetConnectionString(), "orders");
        await client.CreateIfNotExistsAsync();

        var repository = new TableStorageOrderRepository(client);
        var order = new Order("ORD-TEST01", "WIDGET-42", 3);

        await repository.SaveAsync(order);

        var entity = await client.GetEntityAsync<TableEntity>(
            order.ProductId, order.OrderId);
        Assert.Equal(3, entity.Value["Quantity"]);
    }

    public async Task DisposeAsync() => await _azurite.DisposeAsync();
}

Add one package to the test project:

<PackageReference Include="Testcontainers.Azurite" />

Each test run gets a fresh container. No ports to reserve, no cleanup between runs; Testcontainers handles port allocation for parallel CI execution automatically.

The same pattern covers blob and queue operations. For relational databases, Testcontainers.MsSql and Testcontainers.PostgreSql provide the same lifecycle wrapper for SQL Server and Postgres.

---

Local E2E testing with func start + Azurite

Logic tests cover OrderService. Repository tests cover TableStorageOrderRepository. Neither covers what happens when the Functions host receives an HTTP request, routes it through middleware, deserializes the body, calls the function, and returns a response.

For that, the host must be running. The approach is to start Azurite and func start together in the test fixture:

public class FunctionsE2ETests : IAsyncLifetime
{
    private readonly AzuriteContainer _azurite = new AzuriteBuilder().Build();
    private Process? _funcProcess;
    private readonly HttpClient _client = new();

    public async Task InitializeAsync()
    {
        await _azurite.StartAsync();

        _funcProcess = Process.Start(new ProcessStartInfo
        {
            FileName = "func",
            Arguments = "start --port 7071",
            WorkingDirectory = Path.GetFullPath("../../../HttpTriggerDemo"),
            EnvironmentVariables =
            {
                ["AzureWebJobsStorage"] = _azurite.GetConnectionString(),
                ["FUNCTIONS_WORKER_RUNTIME"] = "dotnet-isolated"
            },
            RedirectStandardOutput = true,
            UseShellExecute = false
        });

        await WaitForHostReady(_funcProcess, TimeSpan.FromSeconds(30));
    }

    [Fact]
    public async Task CreateOrder_WithValidRequest_Returns201()
    {
        var response = await _client.PostAsJsonAsync(
            "http://localhost:7071/api/orders",
            new CreateOrderRequest("WIDGET-42", 3));

        Assert.Equal(HttpStatusCode.Created, response.StatusCode);
    }

    private static async Task WaitForHostReady(Process process, TimeSpan timeout)
    {
        var ready = new TaskCompletionSource<bool>();
        process.OutputDataReceived += (_, e) =>
        {
            if (e.Data?.Contains("Host started") == true)
                ready.TrySetResult(true);
        };
        process.BeginOutputReadLine();
        await ready.Task.WaitAsync(timeout);
    }

    public async Task DisposeAsync()
    {
        _funcProcess?.Kill(entireProcessTree: true);
        await _azurite.DisposeAsync();
        _client.Dispose();
    }
}

func must be on the PATH. CI pipelines need npm install -g azure-functions-core-tools@4 before these tests run: it's a test infrastructure dependency that bites if you assume it's there.

Kill(entireProcessTree: true) matters on Windows. func start spawns child processes; killing just the parent leaves orphaned processes holding port 7071, which causes every subsequent E2E test run in that session to hang on startup.

WaitForHostReady polls stdout for "Host started". Startup takes 3-10 seconds depending on cold JIT and machine speed. Set the timeout conservatively: a flaky timeout is harder to debug than a slow test.

Put these tests in a separate project with [Trait("Category", "E2E")] and exclude them from the fast inner development loop. They're most useful in CI as a gate before deployment, not as daily feedback during development.

---

Testing an event-driven function

HTTP triggers test cleanly: call the function directly, inspect the return value. Event Hub triggers are different. The function receives a batch of EventData, deserializes each message, and delegates to a service; the trigger binding itself is provided by the runtime. That runtime can run locally.

The scenario here is an IoT pipeline: devices publish sensor readings to an Event Hub, and a function consumes the batch, validates each reading, and writes to Cosmos DB.

The function

The function stays thin. Deserialize the batch, call the service, nothing else:

public class SensorReadingFunction(
    ILogger<SensorReadingFunction> logger,
    ISensorProcessor processor)
{
    [Function(nameof(SensorReadingFunction))]
    public async Task Run(
        [EventHubTrigger("sensor-readings", Connection = "EventHubConnection")]
        EventData[] events)
    {
        logger.LogInformation("Processing batch of {Count} events", events.Length);

        foreach (var eventData in events)
        {
            var reading = JsonSerializer.Deserialize<SensorReading>(eventData.Body.Span);
            if (reading is null) continue;

            await processor.ProcessAsync(reading);
        }
    }
}

The EventData[] parameter receives the batch. The function doesn't know or care how many partitions the hub has, how messages were routed, or what retry policy applies: that's the runtime's job.

Unit testing the function

Construct EventData directly with a JSON body and call Run(). No containers, no emulator:

[Fact]
public async Task Run_WithBatchOfThreeEvents_CallsProcessorThreeTimes()
{
    var processor = Substitute.For<ISensorProcessor>();
    var function = new SensorReadingFunction(NullLogger<SensorReadingFunction>.Instance, processor);

    EventData[] events =
    [
        CreateEventData(new SensorReading("device-01", 22.5, 60.0, DateTimeOffset.UtcNow)),
        CreateEventData(new SensorReading("device-02", 25.0, 55.0, DateTimeOffset.UtcNow)),
        CreateEventData(new SensorReading("device-03", 18.3, 72.0, DateTimeOffset.UtcNow)),
    ];

    await function.Run(events);

    await processor.Received(3).ProcessAsync(Arg.Any<SensorReading>());
}

private static EventData CreateEventData(SensorReading reading)
    => new(JsonSerializer.SerializeToUtf8Bytes(reading));

This catches deserialization bugs and verifies the batch loop without starting anything.

Full trigger integration test

Unit tests verify the dispatch and deserialization logic in isolation. The full pipeline test goes further: a real message flows from Event Hubs through the function and into Cosmos DB.

The fixture starts three containers in parallel (Azurite for the Functions runtime, the Event Hubs emulator, and the Cosmos DB emulator), then launches func start as a child process wired to all three. The full source is in SensorPipelineFixture.cs. The container declarations and process wiring both require non-obvious configuration.

Container configuration:

// Use latest: Core Tools 4.8 sends an API version that Azurite 3.28.0 (the Testcontainers default) rejects.
private readonly AzuriteContainer _azurite = new AzuriteBuilder()
    .WithImage("mcr.microsoft.com/azure-storage/azurite:latest")
    .Build();

// WithPortBinding pins the host port so localhost:8081 resolves from the func child process.
private readonly CosmosDbContainer _cosmos = new CosmosDbBuilder()
    .WithImage("mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview")
    .WithPortBinding(8081, 8081)
    .WithWaitStrategy(Wait.ForUnixContainer()
        .UntilMessageIsLogged("Gateway=OK, Explorer=OK"))
    .Build();

private readonly EventHubsContainer _eventHubs;

public SensorPipelineFixture()
{
    _eventHubs = new EventHubsBuilder()
        .WithAcceptLicenseAgreement(true)
        .WithConfigurationBuilder(EventHubsServiceConfiguration.Create()
            .WithEntity("sensor-readings", 2, []))
        .WithWaitStrategy(Wait.ForUnixContainer()
            .UntilMessageIsLogged("Emulator Service is Successfully Up!"))
        .Build();
}

Testcontainers pins azurite:3.28.0 as its default. Azure Functions Core Tools 4.8 sends API version 2024-08-04; Azurite 3.28.0 rejects that version with a 400. Pinning to latest resolves it.

Both the Event Hubs emulator and the Cosmos vnext-preview image are distroless: no shell, no /bin/sh. The default Testcontainers port-check wait strategy execs /bin/sh inside the container to verify the port is listening. On a distroless image, that exec fails and the strategy hangs indefinitely. UntilMessageIsLogged() watches the container's stdout stream directly, bypassing the shell dependency.

The Cosmos emulator returns its own internal address in the account metadata it sends back to clients. The test-process CosmosClient receives localhost:8081 as the endpoint and follows it there. WithPortBinding(8081, 8081) ensures that host port is pinned, so the func child process (which constructs its own CosmosClient) lands on the same address.

WithResourceMapping mounts a JSON configuration file into the Event Hubs emulator container, but it doesn't set the ServiceConfiguration property the builder reads at Build() time. The build throws at runtime. WithConfigurationBuilder uses the fluent API to set ServiceConfiguration directly, and the configuration is validated at build time.

Process wiring:

var cosmosPort = _cosmos.GetMappedPublicPort(8081);
var cosmosKey = _cosmos.GetConnectionString()
    .Split(';').First(p => p.StartsWith("AccountKey=", StringComparison.Ordinal))
    .Substring("AccountKey=".Length);

CosmosClient = new CosmosClient(
    _cosmos.GetConnectionString(),
    new CosmosClientOptions
    {
        ConnectionMode = ConnectionMode.Gateway,
        HttpClientFactory = () => new HttpClient(new CosmosEmulatorHandler(cosmosPort)),
        SerializerOptions = new CosmosSerializationOptions
        {
            PropertyNamingPolicy = CosmosPropertyNamingPolicy.CamelCase
        }
    });

startInfo.Environment["CosmosDbConnection"] =
    $"AccountEndpoint=http://localhost:{cosmosPort}/;AccountKey={cosmosKey}";

The func child process constructs its own CosmosClient from the CosmosDbConnection environment variable; it can't share the test process's HttpClient handler across the process boundary. Passing AccountEndpoint=http://localhost:{port}/ with an explicitly extracted key gives the child process a direct HTTP connection to the emulator without needing the handler.

CosmosEmulatorHandler is an HttpMessageHandler that rewrites outgoing requests from the emulator's self-reported internal hostname to localhost:{cosmosPort}. Without it, the SDK follows the internal address the emulator returns in its account metadata and misses the container.

The full fixture also implements WaitForFunctionsHostAsync (polls localhost:7071/admin/host/status until the host responds) and DisposeAsync (kills the process tree and disposes all three containers). Both are in the full source.

The test publishes a batch and polls Cosmos DB until the document appears:

[Collection(SensorPipelineFixture.Name)]
public class SensorPipelineTests(SensorPipelineFixture fixture)
{
    [Fact]
    public async Task PublishedEvent_WithValidReading_AppearsInCosmosDb()
    {
        var reading = new SensorReading(
            DeviceId: $"device-{Guid.NewGuid():N}",
            Temperature: 23.4,
            Humidity: 58.0,
            Timestamp: DateTimeOffset.UtcNow);

        var batch = await fixture.ProducerClient.CreateBatchAsync();
        batch.TryAdd(new EventData(JsonSerializer.SerializeToUtf8Bytes(reading)));
        await fixture.ProducerClient.SendAsync(batch);

        var container = fixture.CosmosClient.GetContainer("SensorData", "readings");
        var deadline = DateTime.UtcNow.AddSeconds(30);
        List<dynamic> results = [];

        while (DateTime.UtcNow < deadline)
        {
            var query = container.GetItemQueryIterator<dynamic>(
                $"SELECT * FROM c WHERE c.deviceId = '{reading.DeviceId}'");
            results.Clear();
            while (query.HasMoreResults)
                results.AddRange(await query.ReadNextAsync());

            if (results.Count > 0) break;
            await Task.Delay(500);
        }

        Assert.Single(results);
        Assert.Equal(23.4, (double)results[0].temperature, precision: 1);
    }
}

The fixture takes 60–90 seconds to start. Run it separately from unit tests in CI using xUnit's [Collection] trait or a test filter.

Add the packages:

<PackageReference Include="Testcontainers.EventHubs" />
<PackageReference Include="Testcontainers.CosmosDb" />
<PackageReference Include="Testcontainers.Azurite" />
<PackageReference Include="Azure.Messaging.EventHubs" />
<PackageReference Include="Newtonsoft.Json" />

Cosmos SDK v3 requires Newtonsoft.Json at runtime via an internal dependency. Omitting it produces a FileNotFoundException at startup with no message connecting it to Cosmos.

---

What can't be emulated locally

Azurite and func start cover wiring and trigger dispatch. Some behaviors only emerge in Azure.

Cold starts. Local tests keep the host warm throughout the run. Consumption plan cold starts in Azure hit 500ms-2s for .NET depending on deployment size. If your SLA depends on p99 latency, that gap only shows in production traffic — local tests give you no signal on it.

Managed identity credential resolution. DefaultAzureCredential falls through a chain of credential sources. Locally it uses developer machine credentials or environment variables. In Azure it uses the Managed Identity endpoint. A misconfigured client ID or missing role assignment won't surface until the function runs with a real identity attached. The local credential chain doesn't exercise the same code path.

Scale-out behavior. func start runs one worker. Azure scales to N workers based on trigger backlog. Race conditions, partition contention, and shared-state bugs appear only under concurrent load across multiple instances. No local setup replicates this.

KEDA-based scaling decisions. Event Hub and Service Bus triggers scale based on message lag, but the scaling decisions come from the infrastructure, not the worker process. There's no local equivalent for how Azure routes partitions across workers as instances scale up.

The useful takeaway: unit tests and integration tests give fast, reliable feedback on logic and wiring. They don't give confidence about latency under cold conditions, behavior at scale, or cloud-managed auth. Build those signals from production observability (Application Insights, structured logs, alert rules), not from test infrastructure.

---

Patterns that cause pain

A few mistakes appear repeatedly in Azure Functions test suites.

Asserting on log messages. Substitute.For<ILogger<T>>() lets you verify that specific log calls were made. Don't. Log messages are implementation details: they change wording, get split into multiple calls, or get removed during refactoring. When they do, your test breaks without any behavior change. Use NullLogger<T>.Instance for services and only substitute loggers when logging output is the actual behavior under test (which is almost never).

Reaching into the runtime from unit tests. [HttpTrigger], [FromBody], and [QueueTrigger] are metadata for the runtime to read. They don't execute during a direct method call. Trying to test that binding attributes are present, or that the runtime would route correctly, puts you in the business of testing the Functions SDK rather than your code. The routing table lives in the host config; your job is to test what happens once the host calls your method.

Using constructors for container lifecycle. xUnit creates test class instances before running tests, but StartAsync() is async. Initializing a AzuriteContainer in a constructor blocks the thread and causes tests to hang silently. Always use IAsyncLifetime: InitializeAsync for startup, DisposeAsync for teardown.

Testing the service layer twice. Once you have thorough OrderServiceTests, the function-level tests (OrderFunctionTests) should only cover the HTTP response mapping: does a successful result return 201, does a failure return 400. Repeating the validation and business logic assertions at the function level creates duplicate coverage that breaks together whenever the service contract changes.

---

Choosing your testing strategy

Layer	Approach	Infrastructure needed
Service logic	Unit test	None
Function routing	Unit test	None
DI wiring + middleware	HostBuilder trick	None (gRPC stripped)
Data layer round-trips	Testcontainers (SQL/Postgres/Azurite)	Docker
Trigger dispatch	func start + Azurite	Core Tools + Docker
Full pipeline	Testcontainers Docker image	Docker

Start from the top and stop as soon as the tests cover the risk you're managing. For most business logic, unit tests against the service layer are enough. The function class tests add a few minutes of coverage for the HTTP response shapes. Integration and E2E tests are worth the infrastructure cost only when you need to verify wiring, real database behavior, or trigger dispatch.

---

Do you unit test your function class directly, or do you treat the service layer as the boundary and skip function-level tests entirely?

---

Azure Functions for .NET Developers: Series

• Part 1: Why Azure Functions? Serverless for .NET Developers
• Part 2: Your First Azure Function: HTTP Triggers Step-by-Step
• Part 3: Beyond HTTP: Timer, Queue, and Blob Triggers
• Part 4: Local Development Setup: Tools, Debugging, and Hot Reload
• Part 5: Understanding the Isolated Worker Model
• Part 6: Configuration Done Right: Settings, Secrets, and Key Vault
• Part 7: Testing Azure Functions: Unit, Integration, and Local ← you are here
• Part 8: Deploying to Azure: CI/CD with GitHub Actions (coming next week)

---