Единицы Метод испытания асинхронный: Как явно утверждать, что внутренняя задача была отменена

Question

я недавно пишу асинхронную метод, который вызывает внешний длинный ход асинхронная метод, поэтому я решил передать CancellationToken позволяющих отменить. Метод можно вызвать одновременно.

Реализации объединила экспоненциальную отсрочку передачи и тайма-аута методов, описанных в Stephen Cleary «ы Книги Параллелизм в C# Поваренной следующим образом;

/// <summary> 
/// Sets bar 
/// </summary> 
/// <param name="cancellationToken">The cancellation token that cancels the operation</param> 
/// <returns>A <see cref="Task"/> representing the task of setting bar value</returns> 
/// <exception cref="OperationCanceledException">Is thrown when the task is cancelled via <paramref name="cancellationToken"/></exception> 
/// <exception cref="TimeoutException">Is thrown when unable to get bar value due to time out</exception> 
public async Task FooAsync(CancellationToken cancellationToken) 
{ 
    TimeSpan delay = TimeSpan.FromMilliseconds(250); 
    for (int i = 0; i < RetryLimit; i++) 
    { 
     if (i != 0) 
     { 
      await Task.Delay(delay, cancellationToken); 
      delay += delay; // Exponential backoff 
     } 

     await semaphoreSlim.WaitAsync(cancellationToken); // Critical section is introduced for long running operation to prevent race condition 

     using (CancellationTokenSource cancellationTokenSource = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken)) 
     { 
      cancellationTokenSource.CancelAfter(TimeSpan.FromMilliseconds(Timeout)); 
      CancellationToken linkedCancellationToken = cancellationTokenSource.Token; 

      try 
      { 
       cancellationToken.ThrowIfCancellationRequested(); 
       bar = await barService.GetBarAsync(barId, linkedCancellationToken).ConfigureAwait(false); 

       break; 
      } 
      catch (OperationCanceledException) when (!cancellationToken.IsCancellationRequested) 
      { 
       if (i == RetryLimit - 1) 
       { 
        throw new TimeoutException("Unable to get bar, operation timed out!"); 
       } 

       // Otherwise, exception is ignored. Will give it another try 
      } 
      finally 
      { 
       semaphoreSlim.Release(); 
      } 
     } 
    } 
} 

Интересно, если я должен написать модульный тест, который явно утверждает, что внутренняя задача barService.GetBarAsync() отменяется, когда FooAsync() отменяется. Если да, то как его реализовать чисто?

Кроме того, следует ли игнорировать детали реализации и просто проверять, что такое клиент/вызывающий, как описано в сводке методов (строка обновлена, триггеры отмены OperationCanceledException, таймеры тайм-аута TimeoutException).

Если нет, то я должен получить мои ноги мокрые и приступить к реализации модульных тестов для следующих случаев:

1. Тестирование является поточно-(монитор приобретается только по одной нити в то время)
2. Тестирование повторить механизм
3. Тестирование сервера не затопило
4. Тестирование может быть, даже регулярное исключение передается вызывающему абоненту

Answer 1

Интересно, следует ли мне написать единичный тест, который явно утверждает, что внутренняя задача barService.GetBarAsync() отменяется всякий раз, когда FooAsync() отменяется.

Было бы легче написать тест, который утверждает, что отмены маркера передается GetBarAsync отменяется, когда отмена маркер передается FooAsync отменяются.

Для асинхронных модульных испытаний мой сигнал выбора - TaskCompletionSource<object> для асинхронных сигналов и ManualResetEvent для синхронных сигналов. Поскольку GetBarAsync асинхронный, я хотел бы использовать асинхронный один, например,

var cts = new CancellationTokenSource(); // passed into FooAsync 
var getBarAsyncReady = new TaskCompletionSource<object>(); 
var getBarAsyncContinue = new TaskCompletionSource<object>(); 
bool triggered = false; 
[inject] GetBarAsync = async (barId, cancellationToken) => 
{ 
    getBarAsyncReady.SetResult(null); 
    await getBarAsyncContinue.Task; 
    triggered = cancellationToken.IsCancellationRequested; 
    cancellationToken.ThrowIfCancellationRequested(); 
}; 

var task = FooAsync(cts.Token); 
await getBarAsyncReady.Task; 
cts.Cancel(); 
getBarAsyncContinue.SetResult(null); 

Assert(triggered); 
Assert(task throws OperationCanceledException); 

Вы можете использовать сигналы, как это, чтобы создать своего рода «замок-шаг».

---

Сторона примечания: в моем собственном коде я никогда не пишу логику повтора. Я использую Polly, который полностью async-совместим и тщательно протестирован. Это позволит сократить семантику, которые должны быть проверены до:

1. КТ проходит через (косвенно) к способу обслуживания, в результате чего OperationCanceledException при срабатывании.
2. Существует также тайм-аут, в результате которого TimeoutException.
3. Выполнение mutex'ed.

(1) будет выполнен точно так же, как указано выше. (2) и (3) менее просты в тестировании (для правильных тестов, требующих либо MS Fakes, либо абстракции для времени/мьютекса). Конечно, есть определенная точка снижения прибыли, когда дело доходит до модульного тестирования, и вам решать, как далеко вы хотите идти.