Why Async Matters for Test Automation

Before going deep into mechanics, it's worth establishing precisely why asynchronous programming matters more for test code than many developers initially expect. The intuitive answer – "tests call async APIs, so tests must be async" – is true but incomplete. The deeper answer is that async unlocks a fundamentally different model for test design.

Consider the three categories of operations that dominate test execution time: I/O-bound work (database queries, API calls, file reads), network-bound work (HTTP requests, message queue interactions, WebSocket connections), and UI synchronization (waiting for elements to appear, animations to complete, background jobs to finish). None of these operations require the CPU. They're all waiting. A synchronous thread blocked on a database query is a thread doing nothing – consuming OS resources, holding thread pool slots, and preventing other work from progressing.

Async rewires this. When an operation needs to wait for I/O, the thread returns to the pool and becomes available for other work. When the I/O completes, a thread from the pool resumes execution at the point where it left off. For test automation, this means:

• Parallel test data setup: Creating a test user, seeding products, and initializing categories can all happen concurrently rather than sequentially.
• Efficient API testing: An async HTTP client can issue multiple requests simultaneously and wait for all responses without blocking.
• Non-blocking waits: Polling for a UI condition with Task.Delay releases the thread between polls instead of spinning.
• Scalable parallel test execution: Async-aware tests run higher parallelism without exhausting the thread pool.

Understanding async isn't just about correctly using APIs that happen to return Task – it's about writing test infrastructure that scales efficiently with the demands of modern test suites.

Tasks and the Async Foundation

The central abstraction of C# asynchronous programming is Task. A Task represents an operation that will produce a result at some point in the future – or may have already completed. It carries the operation's status (pending, completed, faulted, or cancelled), its result when successful, and any exception it threw. Crucially, a Task is not a thread: it's a handle to a promise that might be backed by a thread pool thread, an I/O completion callback, a timer, or even synchronous code that simply returned a Task.

Task and Task<T>

Task represents an async operation with no meaningful return value. Task<T> represents an operation that produces a value of type T. These map directly to void and T in synchronous code:

// Synchronous: returns void (no useful return value)
public void SetupTestDatabase() { /* ... */ }

// Async equivalent: returns Task
public async Task SetupTestDatabaseAsync() { /* ... */ }

// Synchronous: returns a created user
public User CreateTestUser(string email) { /* ... */ }

// Async equivalent: returns Task<User>
public async Task<User> CreateTestUserAsync(string email) { /* ... */ }

// Awaiting Task<T> unwraps the result directly
User user = await CreateTestUserAsync("[email protected]");

// Awaiting Task just waits for completion (no result to unwrap)
await SetupTestDatabaseAsync();

ValueTask and ValueTask<T>

ValueTask is a struct-based alternative to Task, introduced to reduce heap allocations in performance-critical scenarios. Allocating a Task object on the heap for every async call is usually acceptable – but in high-frequency code paths (tight loops, frequently called utility methods), the allocation pressure accumulates. ValueTask can represent a result that's already available without any heap allocation:

// ValueTask is ideal when the result is often synchronously available
// e.g., a cache lookup that may not need to hit the database
public async ValueTask<Product> GetProductAsync(int productId)
{
    // Check in-memory cache first – no allocation needed if hit
    if (_cache.TryGetValue(productId, out var cached))
        return cached; // Returns synchronously, no Task allocation

    // Cache miss: perform async database lookup
    var product = await _database.QuerySingleAsync<Product>(
        "SELECT * FROM Products WHERE ProductId = @Id",
        new { Id = productId });

    _cache[productId] = product;
    return product;
}

// Caller code is identical – ValueTask is awaitable just like Task
var product = await GetProductAsync(42);

The Task/Task<T> pair handles the overwhelming majority of async test automation scenarios. Understanding them as "promises" – objects that represent future results – rather than "threads" is the conceptual shift that makes everything else about async click into place.

How the Compiler Rewrites Async Methods

The async and await keywords are compiler magic – but understanding what the compiler generates is not optional at the Voyager level. The generated code determines performance characteristics, exception propagation behaviour, and why certain async patterns deadlock. The compiler transforms every async method into a state machine: a struct that implements IAsyncStateMachine and tracks the method's progress through each await point.

Consider a simple async method:

// What you write:
public async Task<Order> GetOrderAsync(int orderId)
{
    // State 0: before first await
    await _connection.OpenAsync();

    // State 1: after OpenAsync, before second await
    var order = await _repository.FindOrderAsync(orderId);

    // State 2: after FindOrderAsync
    return order;
}

The compiler rewrites this into roughly the following structure (simplified for clarity – actual generated IL is more complex):

// What the compiler generates (conceptually):
private struct GetOrderAsyncStateMachine : IAsyncStateMachine
{
    // State tracking: which await point are we at?
    public int _state;

    // The async method builder – manages the Task and its completion
    public AsyncTaskMethodBuilder<Order> _builder;

    // Captured local variables (cross await-boundary variables become fields)
    public int _orderId;
    private Order _order;

    // Awaiter storage for each await point
    private TaskAwaiter _openAwaiter;
    private TaskAwaiter<Order> _findAwaiter;

    public void MoveNext()
    {
        try
        {
            if (_state == 0)
            {
                // First await: start OpenAsync and check if already done
                _openAwaiter = _connection.OpenAsync().GetAwaiter();
                if (!_openAwaiter.IsCompleted)
                {
                    _state = 1;
                    _builder.AwaitUnsafeOnCompleted(ref _openAwaiter, ref this);
                    return; // Yield back to caller – thread is free
                }
            }

            if (_state == 1)
            {
                _openAwaiter.GetResult(); // Rethrows exceptions if faulted

                // Second await: start FindOrderAsync
                _findAwaiter = _repository.FindOrderAsync(_orderId).GetAwaiter();
                if (!_findAwaiter.IsCompleted)
                {
                    _state = 2;
                    _builder.AwaitUnsafeOnCompleted(ref _findAwaiter, ref this);
                    return; // Yield again – thread is free
                }
            }

            if (_state == 2)
            {
                _order = _findAwaiter.GetResult();
                _builder.SetResult(_order); // Complete the Task<Order>
            }
        }
        catch (Exception ex)
        {
            _builder.SetException(ex); // Fault the Task<Order>
        }
    }
}

The Synchronous Completion Fast Path

The IsCompleted short-circuit is critical for understanding async performance. When an awaited operation completes synchronously – common for in-memory operations wrapped in Task.FromResult, cached results, or hardware that responds immediately – the state machine never yields. The method runs to completion on the calling thread with no scheduling overhead:

// This method appears async but may complete entirely synchronously on a cache hit
public async Task<string> GetCachedValueAsync(string key)
{
    if (_cache.TryGetValue(key, out var value))
        return value; // No await reached – zero state machine overhead

    // Only reaches here on a cache miss
    var result = await _slowDataSource.FetchAsync(key);
    _cache[key] = result;
    return result;
}

// A cache hit calls through this method at near-synchronous speed.
// The async machinery is present but dormant until actually needed.

The state machine model is an elegant solution to a hard problem: expressing sequential-looking async code while achieving the non-blocking efficiency of callback-based I/O. Once you can reason about what the state machine is doing at any point, deadlocks, exception-handling surprises, and performance puzzles become predictable rather than mysterious.

ConfigureAwait and Synchronization Context

The question of where an async continuation runs – which thread picks up execution after an await completes – is governed by the synchronization context captured when the await is first encountered. This detail sits behind one of async's most common and confusing failure modes: deadlocks in test code.

What Synchronization Context Does

A synchronization context is an abstraction that determines how work is dispatched to a particular threading model. The classic UI thread context ensures all continuations run on the UI thread. ASP.NET classic (pre-Core) captured the request context. Some test runners install their own contexts to manage test isolation. When no special context is present – the default in .NET Core, .NET 5+, and most console applications – continuations run on thread pool threads.

The issue arises when code captures a single-threaded synchronization context and then blocks that thread waiting for an async operation to complete:

// DANGEROUS PATTERN – can deadlock in any context that uses a
// single-threaded synchronization context
public void SetupSync()
{
    // .Result blocks the current thread and waits for the Task to complete
    var user = CreateUserAsync().Result; // POTENTIAL DEADLOCK

    // What happens step by step:
    // 1. CreateUserAsync() starts and reaches an internal await
    // 2. The await captures the current synchronization context
    // 3. When the awaited operation completes, it tries to resume on that context
    // 4. But .Result is blocking that context thread – it cannot process work
    // 5. Deadlock: .Result waits for CreateUserAsync, CreateUserAsync
    //    waits for .Result to release the context
}

// SAFE: always await async methods
public async Task SetupAsync()
{
    var user = await CreateUserAsync(); // Correct: no blocking, no deadlock risk
}

ConfigureAwait(false) Explained

ConfigureAwait(false) instructs the awaiter not to capture the current synchronization context. The continuation will run on any available thread pool thread instead of the original context's thread. This both avoids potential deadlocks and removes the overhead of marshalling the continuation back to a specific thread:

// In library/utility code: use ConfigureAwait(false) to avoid
// unnecessarily capturing and resuming on the caller's context
public async Task<IEnumerable<Product>> LoadProductsAsync(int categoryId)
{
    // After this await completes, resume on any thread pool thread
    var products = await _repository.GetByCategoryAsync(categoryId)
        .ConfigureAwait(false);

    // This code runs on a thread pool thread – no context marshalling needed
    return products.Where(p => p.IsActive).OrderBy(p => p.Name);
}

// In test method code: ConfigureAwait(false) is optional in .NET Core+ because
// the default synchronization context is null – but it's still good practice
[Test]
public async Task Products_ShouldLoad_ForValidCategory()
{
    // await in test methods: never .Result, never .Wait()
    var products = await _service.LoadProductsAsync(categoryId: 1);
    Assert.That(products, Is.Not.Empty);
}

ConfigureAwait Guidance in Practice

For modern .NET test projects targeting .NET Core or .NET 5+, ConfigureAwait(false) in test methods is a matter of style rather than correctness – the default synchronization context is null, so there's nothing to capture. However, it's worth adding to shared utility and helper methods that might be reused outside test contexts:

// Test helper reusable across test and application code:
// Use ConfigureAwait(false) for library-style helpers
public static async Task<bool> WaitForConditionAsync(
    Func<Task<bool>> condition,
    TimeSpan timeout)
{
    var deadline = DateTime.UtcNow + timeout;
    while (DateTime.UtcNow < deadline)
    {
        if (await condition().ConfigureAwait(false))
            return true;
        await Task.Delay(100).ConfigureAwait(false);
    }
    return false;
}

// Test method: ConfigureAwait(false) is optional in .NET Core+ test methods
[Test]
public async Task Order_ShouldBeProcessed_WithinTimeout()
{
    await PlaceOrderAsync(_testOrder);

    var processed = await WaitForConditionAsync(
        async () =>
        {
            var status = await _orderService.GetStatusAsync(_testOrder.OrderId);
            return status == "Processed";
        },
        timeout: TimeSpan.FromSeconds(10));

    Assert.That(processed, Is.True, "Order was not processed within 10 seconds.");
}

The synchronization context system is one of C#'s more complex corners – infrastructure designed to bridge async code to single-threaded event loop environments that are increasingly rare in modern development. For test automation specifically, the practical rule is straightforward: never block on async operations, always use await, and add ConfigureAwait(false) to shared utility code that may run in diverse contexts.

Parallel Async with WhenAll and WhenAny

await in sequence executes one async operation at a time, waiting for each to complete before starting the next. That's correct when operations depend on each other's results. But when operations are independent, sequential awaiting is pure waste. Task.WhenAll and Task.WhenAny express explicit parallelism: start multiple operations simultaneously and coordinate their completion without blocking any thread.

Task.WhenAll – Wait for All

Task.WhenAll takes a collection of tasks, starts them all immediately, and returns a single task that completes when all of the input tasks have completed. If any task faults, the returned task also faults. This is the primary tool for parallel test data setup:

// Sequential setup (slow – each operation waits for the previous):
public async Task SetupSequentialAsync()
{
    var user      = await CreateTestUserAsync("[email protected]");  // 200ms
    var category  = await CreateCategoryAsync("Electronics");         // 150ms
    var products  = await CreateProductsAsync(category.CategoryId);   // 300ms
    var orders    = await CreateOrdersAsync(user.UserId, 3);          // 250ms
    // Total: ~900ms (each waits for the previous)
}

// Parallel setup (fast – independent operations run simultaneously):
public async Task<TestContext> SetupParallelAsync()
{
    // Start all independent operations at once.
    // Tasks START immediately when created – not when awaited.
    var userTask     = CreateTestUserAsync("[email protected]");
    var categoryTask = CreateCategoryAsync("Electronics");

    // Wait for both to complete before creating dependent resources
    await Task.WhenAll(userTask, categoryTask);

    // Results are already available – awaiting a completed Task is instantaneous
    var user     = await userTask;
    var category = await categoryTask;

    // Products and orders depend on user/category, but not on each other
    var productsTask = CreateProductsAsync(category.CategoryId, count: 5);
    var ordersTask   = CreateOrdersAsync(user.UserId, count: 3);

    await Task.WhenAll(productsTask, ordersTask);

    return new TestContext(user, await productsTask, await ordersTask, category);
    // Total: ~500ms (max of each parallel group, not sum of all)
}

Collecting Results from WhenAll

When all tasks share the same result type, Task.WhenAll has a typed overload that returns all results as an array directly, eliminating the need to await each task separately:

// Create multiple test products concurrently and collect all results
public async Task<IReadOnlyList<Product>> CreateTestProductsAsync(
    int categoryId,
    int count)
{
    // Build one Task<Product> per product to create
    var creationTasks = Enumerable.Range(1, count)
        .Select(i => CreateSingleProductAsync(
            name:       $"Test Product {i:D3}",
            price:      9.99m * i,
            categoryId: categoryId,
            stock:      100))
        .ToList();

    // WhenAll returns Task<Product[]> when all tasks share the same type
    Product[] products = await Task.WhenAll(creationTasks);
    return products;
}

// Practical pattern: validate all API endpoints in parallel
[Test]
public async Task AllProductEndpoints_ShouldReturn200()
{
    var productIds = await GetActiveProductIdsAsync();

    // Fire all HTTP requests simultaneously
    var responseTasks = productIds
        .Select(id => _httpClient.GetAsync($"/api/products/{id}"))
        .ToList();

    var responses = await Task.WhenAll(responseTasks);

    var failures = responses
        .Where(r => !r.IsSuccessStatusCode)
        .ToList();

    Assert.That(failures, Is.Empty,
        $"{failures.Count} product endpoints returned non-success status.");
}

Task.WhenAny – First to Complete Wins

Task.WhenAny completes as soon as the first of its input tasks completes, returning that task. This is the correct primitive for timeout patterns – racing a real operation against a deadline signal:

// Implementing a timeout wrapper using WhenAny
public async Task<T> WithTimeoutAsync<T>(Task<T> operation, TimeSpan timeout)
{
    using var cts     = new CancellationTokenSource();
    var timeoutTask   = Task.Delay(timeout, cts.Token);

    var winner = await Task.WhenAny(operation, timeoutTask);

    if (winner == timeoutTask)
    {
        throw new TimeoutException(
            $"Operation did not complete within {timeout.TotalSeconds:F1}s.");
    }

    // Operation won – cancel the timer to release its resources
    cts.Cancel();

    // Re-await the winning task to unwrap the result (and propagate any exception)
    return await operation;
}

// Usage: any async operation can be guarded with a timeout
[Test]
public async Task OrderProcessing_ShouldComplete_WithinFiveSeconds()
{
    var orderId = await CreateAndSubmitOrderAsync();

    var status = await WithTimeoutAsync(
        PollForOrderStatusAsync(orderId, targetStatus: "Processed"),
        timeout: TimeSpan.FromSeconds(5));

    Assert.That(status, Is.EqualTo("Processed"));
}

var allTask = Task.WhenAll(task1, task2, task3);
try
{
    await allTask;
}
catch
{
    // allTask.Exception contains ALL faults as an AggregateException
    var allFailures = allTask.Exception?.InnerExceptions
                     ?? Array.Empty<Exception>();

    foreach (var ex in allFailures)
        TestContext.WriteLine($"Failure: {ex.Message}");

    throw; // Re-throw to fail the test
}

Task.WhenAll is the single most impactful async pattern for test automation performance. Identifying which parts of test setup are logically independent and running them in parallel is often the easiest way to cut suite setup time by 30–60% without changing a single assertion.

Cancellation with CancellationToken

Async operations can run indefinitely if nothing stops them. A database query against a slow server, an HTTP request to an unresponsive endpoint, a polling loop waiting for a condition that never arrives – all of these can hang test execution for minutes without a mechanism to stop them. CancellationToken is C#'s cooperative cancellation model: a signal that any async operation can observe and honour by stopping work cleanly.

The pattern has two sides: the CancellationTokenSource is the sender of the cancellation signal, and the CancellationToken obtained from source.Token is the receiver that code checks. Libraries pass the token to every async API that accepts one; the runtime propagates it through await chains automatically:

// Creating a source that cancels automatically after a timeout
public async Task<Order> FetchOrderWithTimeoutAsync(int orderId)
{
    // Source cancels after 30 seconds – disposing also cancels it
    using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(30));

    try
    {
        // Pass the token to every async operation that accepts one
        await _connection.OpenAsync(cts.Token);
        var order = await _repository.FindOrderAsync(orderId, cts.Token);
        return order;
    }
    catch (OperationCanceledException)
    {
        // Thrown when the token is cancelled – including automatic timeout
        throw new TimeoutException(
            $"Fetching order {orderId} timed out after 30 seconds.");
    }
}

// Accepting a token from a caller and checking it at regular intervals
public async Task ProcessBatchAsync(IEnumerable<int> orderIds, CancellationToken ct = default)
{
    foreach (var orderId in orderIds)
    {
        // ThrowIfCancellationRequested at logical checkpoints
        ct.ThrowIfCancellationRequested();

        await ProcessSingleOrderAsync(orderId, ct);

        // Pass the token to Task.Delay – makes the pause itself cancellable
        await Task.Delay(TimeSpan.FromMilliseconds(50), ct);
    }
}

Linked Token Sources

When a method receives a CancellationToken from a caller and also needs to impose its own timeout, CancellationTokenSource.CreateLinkedTokenSource creates a new source that cancels when either the parent token fires or the local timeout triggers – whichever comes first:

// A polling helper that respects both a caller's token and its own deadline
public async Task<bool> WaitForConditionAsync(
    Func<CancellationToken, Task<bool>> condition,
    TimeSpan timeout,
    TimeSpan pollInterval,
    CancellationToken callerToken = default)
{
    // Link: either source can trigger cancellation
    using var cts = CancellationTokenSource.CreateLinkedTokenSource(callerToken);
    cts.CancelAfter(timeout);

    var linkedToken = cts.Token;

    try
    {
        while (true)
        {
            if (await condition(linkedToken).ConfigureAwait(false))
                return true;

            await Task.Delay(pollInterval, linkedToken).ConfigureAwait(false);
        }
    }
    catch (OperationCanceledException) when (!callerToken.IsCancellationRequested)
    {
        // Our timeout fired, not the caller's – report "not found in time"
        return false;
    }
    // If callerToken fired, OperationCanceledException propagates to the caller
}

// Usage: element visibility wait in a UI test
[Test]
public async Task Checkout_ShouldShowConfirmation_AfterSubmit()
{
    await _page.SubmitOrderAsync();

    var appeared = await WaitForConditionAsync(
        condition:    async ct => await _page.IsConfirmationVisibleAsync(ct),
        timeout:      TimeSpan.FromSeconds(10),
        pollInterval: TimeSpan.FromMilliseconds(250));

    Assert.That(appeared, Is.True, "Confirmation did not appear within 10 seconds.");
}

Cancellation tokens are the mechanism that makes async code interruptible – a critical property in test automation where runaway operations should fail fast rather than blocking the pipeline. Treating CancellationToken as optional is a common early mistake; in production-quality test infrastructure, it belongs on any method that could run for more than a few milliseconds.

Writing Async Tests Correctly

NUnit 3, xUnit 2, and MSTest V2 all support async test methods natively. When a test method returns Task, the test runner awaits it – the test doesn't complete until the task does, and any exception the task carries is treated as a test failure. This makes async test methods feel identical to synchronous ones from the framework's perspective.

Async Test Methods

Marking a test method async Task is all that's required. The framework awaits the task, captures exceptions, and reports failures correctly:

// NUnit: async test methods use [Test] exactly as synchronous tests do
[Test]
public async Task CreateUser_ShouldPersistToDatabase()
{
    // Arrange
    var command = new CreateUserCommand
    {
        Email     = "[email protected]",
        FirstName = "Test",
        LastName  = "User"
    };

    // Act
    var userId = await _userService.CreateAsync(command);

    // Assert: verify via a separate database read
    var stored = await _userRepository.FindByIdAsync(userId);
    Assert.That(stored, Is.Not.Null);
    Assert.That(stored.Email, Is.EqualTo(command.Email));
}

// xUnit: [Fact] and [Theory] work identically for async test methods
[Fact]
public async Task GetOrder_ShouldReturnNull_ForMissingId()
{
    var result = await _orderRepository.FindByIdAsync(orderId: 99999);
    Assert.Null(result);
}

// NUnit: parameterised async tests
[TestCase(1, "Completed")]
[TestCase(2, "Pending")]
public async Task GetOrder_ShouldReturnCorrectStatus(int orderId, string expectedStatus)
{
    var order = await _orderRepository.FindByIdAsync(orderId);
    Assert.That(order?.Status, Is.EqualTo(expectedStatus));
}

Async Lifecycle Methods

NUnit supports async [SetUp], [TearDown], [OneTimeSetUp], and [OneTimeTearDown] methods. xUnit supports async lifecycle via the IAsyncLifetime interface. These allow test data seeding, schema initialization, and resource acquisition to use async patterns throughout:

// NUnit: async lifecycle methods
[TestFixture]
public class OrderIntegrationTests
{
    private IServiceProvider _services;
    private TestContext _context;

    [OneTimeSetUp]
    public async Task OneTimeSetupAsync()
    {
        _services = BuildServiceProvider();
        await InitializeDatabaseSchemaAsync();
    }

    [SetUp]
    public async Task SetUpAsync()
    {
        // Parallel data seeding using WhenAll
        var userTask     = CreateTestUserAsync();
        var categoryTask = CreateCategoryAsync("Electronics");

        await Task.WhenAll(userTask, categoryTask);

        _context = new TestContext(await userTask, await categoryTask);
    }

    [TearDown]
    public async Task TearDownAsync()
    {
        await _context.CleanupAsync();
    }

    [OneTimeTearDown]
    public async Task OneTimeTearDownAsync()
    {
        await ResetDatabaseAsync();
        (_services as IDisposable)?.Dispose();
    }
}

// xUnit: async lifecycle via IAsyncLifetime
public class OrderTests : IAsyncLifetime
{
    private TestContext _context = null!;

    // Called before each test – equivalent to [SetUp]
    public async Task InitializeAsync()
    {
        _context = await TestContext.CreateAsync();
    }

    // Called after each test – equivalent to [TearDown]
    public async Task DisposeAsync()
    {
        await _context.CleanupAsync();
    }

    [Fact]
    public async Task PlaceOrder_ShouldCreateRecord()
    {
        var orderId = await _context.OrderService.PlaceAsync(_context.User.UserId);
        Assert.True(orderId > 0);
    }
}

Common Async Test Mistakes

Several patterns that seem reasonable surface frequently in test codebases and cause silent failures or intermittent flakiness:

// MISTAKE 1: Forgetting to await an async call
[Test]
public async Task Order_ShouldBeCreated()
{
    _orderService.CreateAsync(_testOrder); // Missing 'await' – fire-and-forget!
    // Test proceeds before CreateAsync completes; assertion runs against empty state
    var order = await _repository.FindLatestAsync();
    Assert.That(order, Is.Not.Null); // Likely null – order not yet committed
}

// MISTAKE 2: Blocking on async inside async code
[Test]
public async Task OrderStatus_ShouldUpdate()
{
    // .Result inside an async method is both redundant and potentially deadlocking
    var status = _orderService.GetStatusAsync(_orderId).Result; // Wrong
    var status2 = await _orderService.GetStatusAsync(_orderId); // Correct
}

// MISTAKE 3: Not disposing CancellationTokenSource
public async Task LeakyTimeoutAsync()
{
    // Missing 'using' – the internal timer resource leaks
    var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
    await DoWorkAsync(cts.Token);
}

// CORRECT:
public async Task ProperTimeoutAsync()
{
    using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
    await DoWorkAsync(cts.Token);
} // cts.Dispose() called automatically here, timer released

Async test infrastructure, when written correctly, produces test suites that are faster, more reliable, and more accurate representations of how production async code actually behaves. The framework support is mature; the patterns are well established. The primary requirement is consistency – treating async as a first-class concern rather than an afterthought applied only to APIs that happen to return Task.