Testing for Race Conditions

In this lesson, you will learn how to design integration tests that deliberately induce race conditions to verify the thread-safety of your background message processors.

Why Unit Tests Fall Short

In asynchronous messaging systems, logic that appears correct in a single-threaded unit test often fails under high concurrency. Race conditions occur when multiple workers attempt to mutate shared state (like a database counter or a distributed lock) based on stale information. To catch these, we must shift from testing logic to testing contention.

Simulating Concurrent Pressure

The most effective way to expose these bugs is to use a Task.WhenAll pattern combined with a synchronization primitive like Barrier or TaskCompletionSource to ensure all workers strike the shared resource at the exact same moment.

Consider a scenario where multiple workers process a "Withdraw" event simultaneously. You want to ensure the final balance is consistent despite the concurrent hits:

[Fact]
public async Task ConcurrentProcessing_ShouldMaintainBalanceIntegrity()
{
    // Arrange: Create 10 workers ready to trigger
    int workerCount = 10;
    var startSignal = new TaskCompletionSource<bool>();
    var tasks = Enumerable.Range(0, workerCount).Select(async _ =>
    {
        await startSignal.Task; // Wait for the "Go" signal
        return await _processor.ProcessWithdrawalAsync(accountId: 1, amount: 10);
    });

    // Act: Release all workers at once
    startSignal.SetResult(true);
    await Task.WhenAll(tasks);

    // Assert: Verify if race conditions caused an overdraft or lost updates
    var finalBalance = await _repository.GetBalanceAsync(1);
    Assert.Equal(expectedBalance, finalBalance);
}

The Strategy

1. The "Gate" Pattern: Use TaskCompletionSource to pause all threads, ensuring they are fully initialized before releasing them simultaneously.
2. High Multiplicity: Don't just test with two threads. Scale the number of concurrent tasks to exceed the available thread pool threads to force context switching during the critical section.
3. Observability: Run these tests against a local containerized version of your database (e.g., Testcontainers). If your Optimistic Locking implementation is flawed, the race will cause a DbUpdateConcurrencyException or result in inconsistent data, which your test must catch.

By forcing your system into a state of maximum contention, you transform intermittent "heisenbugs" into deterministic test failures.

Key Takeaway: Never assume thread safety; use a synchronized start signal in your integration tests to force concurrent execution and expose hidden data races.