Concept questionMedium~7 min

Interview question

How would you test an async .NET operation, including cancellation and timeout behavior?

Test async code, cancellation, and timeouts

Tests asynchronous completion, caller cancellation, owned timeouts, cleanup, and race-sensitive side effects deterministically with controlled dependencies and bounded diagnostics.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The test returns Task and awaits the operation; I never use async void. For caller cancellation, I pass a token I own, wait until the operation reaches a known cancellable point, cancel it, and assert the documented outcome such as a canceled task or OperationCanceledException. I also assert state: no database commit, external call, retry, or queued work after cancellation. A product timeout is tested separately so it is not confused with caller cancellation or a test-runner timeout.

Full answer below

Practice focus

Async Task tests, deterministic coordination, cancellation, timeouts, side effects, and failure diagnostics.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
An async test can pass before the real work finishes or become timing-dependent when sleep is used as coordination. A useful test controls the boundary where cancellation or timeout matters and proves both the returned result and the absence of forbidden side effects.
The test returns Task and awaits the operation; I never use async void. For caller cancellation, I pass a token I own, wait until the operation reaches a known cancellable point, cancel it, and assert the documented outcome such as a canceled task or OperationCanceledException. I also assert state: no database commit, external call, retry, or queued work after cancellation. A product timeout is tested separately so it is not confused with caller cancellation or a test-runner timeout.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I replace timing with coordination. A fake dependency can expose one TaskCompletionSource that signals when the call starts and another that lets the test release it. The test awaits the start signal, cancels the token, then observes the operation. RunContinuationsAsynchronously helps prevent the fake from running production continuations inline on the assertion thread. For delay-heavy policies I inject a clock or delay abstraction and advance virtual time. I verify the exact token where that contract matters, but avoid overspecifying internal call order that callers cannot observe.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production-grade tests I model the distinct outcomes explicitly: success before deadline, caller cancellation, component-owned timeout, dependency timeout, retry exhaustion, and a fault unrelated to cancellation. The operation preserves the original cause rather than translating every OperationCanceledException into the same response. For race-sensitive code I add controlled checkpoints around the side effect and cancellation observation, then test both orderings: cancellation wins before commit, or commit wins and the result remains durable. I never use a real sleep to prove thread-pool, timer, or scheduler behavior; it creates slow flaky tests and can hide a deadlock. A bounded outer timeout remains as a safety net and prints pending checkpoint, attempt count, token state, and captured logs when the test hangs. Spawned work is returned, awaited, or owned by a component whose shutdown the test can observe, so no exception escapes after the test completes. Where concurrency creates several valid schedules, assertions focus on invariants such as at-most-one write and no work after ownership ends. Repeating a deterministic schedule can catch a regression; repeating random timing cannot prove correctness.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling an async method without awaiting the returned task.
Sleeping before cancellation and hoping the operation reached the intended point.
Treating caller cancellation, dependency timeout, and runner timeout as one outcome.
Asserting only the exception while a background side effect continues.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The test passes before assertions inside a continuation run.
Cancellation is triggered before the operation reaches the intended boundary.
A hung test has no useful diagnostic state.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid a sleep?
What would you assert after cancellation?
When is virtual time useful?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.