Mocking Async Methods

Question

Stiamo scrivendo unit test per codice asincrono usando MSTest e Moq.

Così abbiamo un codice che sembra qualcosa di simile:

var moq = new Mock<Foo>(); 
moq.Setup(m => m.GetAsync()) 
    .Returns(Task.FromResult(10)); 

O come questo su progetti che hanno una versione più recente di Moq

var moq = new Mock<Foo>(); 
moq.Setup(m => m.GetAsync()) 
    .ReturnsAsync(10); 

Guardando l'attuazione Moq di ReturnsAsync:

public static IReturnsResult<TMock> ReturnsAsync<TMock, TResult>(this IReturns<TMock, Task<TResult>> mock, TResult value) where TMock : class 
{ 
    TaskCompletionSource<TResult> completionSource = new TaskCompletionSource<TResult>(); 
    completionSource.SetResult(value); 
    return mock.Returns(completionSource.Task); 
} 

Entrambi i metodi sembrano essere gli stessi sotto il cofano. Entrambi creano TaskCompletionSource, chiamano SetResult e restituiscono il Task

Fin qui tutto bene.

Ma i metodi corti in esecuzione async sono ottimizzati per agire in modo sincrono. Ciò sembra implicare che TaskCompletionSource sia sempre sincrono, il che sembrerebbe anche suggerire che la gestione del contesto e eventuali problemi correlati che potrebbero verificarsi non si verifichino mai.

Quindi, se abbiamo avuto qualche codice che stava facendo alcuni async no-no, come la miscelazione awaits, Wait() e Result, che questi problemi non sarebbero rilevati nel test di unità.

Potrebbe esserci qualche vantaggio nel creare un metodo di estensione che fornisce sempre il controllo? Qualcosa di simile:

public async Task<T> ReturnsYieldingAsync<T>(T result) 
{ 
    await Task.Yield(); 
    return result; 
} 

In questo caso avremmo un metodo che è garantito per eseguire in modo asincrono.

Il vantaggio percepito potrebbe rilevare un codice asincrono errato. Ad esempio, potrebbe catturare qualsiasi deadlocking o eccezione durante la deglutizione durante il test dell'unità.

Non sono sicuro al 100% che sia così, quindi sarei davvero interessato a sentire ciò che la comunità ha da dire.

Answer 1

Quando ho iniziato a utilizzare talking about testing asynchronous code quattro anni fa (!), Incoraggerei gli sviluppatori a testare l'asse asincrono per i loro mock. Vale a dire, testare l'asse dei risultati (successo, errore) e l'asse asincrono (sincronizzazione, asincrona).

Nel corso del tempo, tuttavia, mi sono allentato. Quando si tratta di testare il mio codice, in realtà testo solo i percorsi sincroni di successo/fallimento, a meno che non ci sia un chiaro motivo per provare anche il percorso di successo asincrono per quel codice. Non mi preoccupo più di test di errore asincrono.