Vantaggio di async/attendere più di blocco in unità di test

Question

moderni unit test framework supportano in attesa dei risultati di un test di unità asincrono, in questo modo:

public async Task SomeTest() 
{ 
    var result = await SomeMethodAsync(); 
    // ... Verify the result ... 
} 

C'è qualche vantaggio di utilizzare questo approccio asincrono rispetto al semplice blocco?

public void SomeTest() 
{ 
    var result = SomeMethodAsync().Result; 
    // ... Verify the result ... 
} 

L'async fornisce un vantaggio solo nell'esecuzione di test in parallelo?

Answer 1

I vantaggi principali di async codice sono un reattivo interfaccia utente sul lato client, e la scalabilità sul lato server. Per i test unitari, si ottiene un po 'di scalabilità (che si traduce in benefici di velocità complessivi poiché i test unitari sono esauriti dalla natura).

Ma non è un enorme vantaggio. I tuoi test sarebbero (probabilmente) un po 'più veloci.

Io di solito uso async Task metodi di prova unità per questi motivi:

• Se si sta testando il codice all'interno di un contesto, quindi il blocco può causare il classico problema deadlock. Nota che alcuni framework (ad es. XUnit) forniscono sempre un contesto per impostazione predefinita. Anche per altri framework, è spesso necessario fornire un contesto ai test di unità ViewModels.
• await non esegue il wrapping delle eccezioni in AggregateException.
• Si ottiene un vantaggio di scalabilità che (in teoria) consente ai test delle unità di funzionare più rapidamente in generale. Supponendo che il tuo framework esegua i test in parallelo.
• Perché no? Sono semplici come i metodi sincroni. async Task metodi di test unitari sono stati supportati da ogni principale test framework dal 2012.

Answer 2

C'è qualche vantaggio nell'usare questo approccio asincrono semplicemente tramite il blocco ?

Penso che in realtà dipende da che cosa stai testando. Se lo guardi dal punto di vista dei framework di test unitari, allora non vedo alcun beneficio qui. Non penso che un tale quadro debba essere scalato rispetto all'IO. L'unica cosa che stai facendo è testare come si comportano le tue API asincrone. Ad esempio, come autore di una libreria, potresti avere un endpoint asincrono e testare cosa succede quando il tuo codice viene bloccato in modo sincrono da un chiamante che non capisce come consumare correttamente la tua libreria.

Un esempio potrebbe essere:

[TestClass] 
public class M 
{ 
    [TestMethod] 
    public void X() 
    { 
     var myService = new MyService(); 
     myService.FetchSomeDataAsync().Result; // Will this deadlock? 
    } 
}