TestMethod: async Task TestSth () non funziona con .NET 4.0

Sto cercando di eseguire metodi di test asincroni con .NET 4.0 BCL Async e MsTest.

Sembra che questa configurazione non sia in grado di gestire [TestMethod] async Task TestSth () a causa di una voce mancante nell’esploratore del caso di test. Dopo aver cambiato la firma in vuoto asincrono, posso eseguire il test case ma con il risultato sbagliato (non verranno segnalati errori).

Ho visto un tentativo durante l’ esecuzione di task asincronici test con TFS 2010, ma penso che ci dovrebbe essere un modo più carino per affrontare il problema.

Eventuali suggerimenti?

È ansible utilizzare solo la parola chiave async con una libreria di classi di riferimento MSTest che utilizza .NET 4.5.

Se non è ansible utilizzare .NET 4.5 per qualsiasi motivo, è sufficiente vivere con l’attesa delle attività manualmente.

E anche se il codice di produzione (cioè il codice in prova) non può utilizzare .NET 4.5, perché il progetto di test non può farlo? Se disponi già di VS 2012+, allora .NET 4.5 verrà installato sul tuo computer di sviluppo.

Ecco una soluzione che funziona per me. È stato un po ‘complicato da capire, ma alla fine tutti i test unitari contro le mie librerie .NET 4.0 sono stati rilevati e visualizzati in Test Explorer, in esecuzione e in transito, e sono tutti scritti come normali metodi async Task , senza alcun test speciale corridori, wrapper o dipendenze di terze parti.

  1. Modificare il Framework di destinazione del progetto di test dell’unità in .NET 4.5.
    • Sì, devi farlo anche se il progetto riporta che stai testando come target .NET 4.0.
  2. Rimuovere i riferimenti del pacchetto NuGet di Microsoft.Bcl , Microsoft.Bcl.Build e Microsoft.Bcl.Async dal progetto di test dell’unità . Se non hai aggiunto questi riferimenti, semplicemente non li aggiungi al tuo progetto di test dell’unità .
  3. Aggiungi System.Runtime.dll e System.Threading.Tasks.dll al progetto di test dell’unità come file collegati nella directory principale del progetto.
    1. Fai clic con il pulsante destro del mouse sul progetto di test dell’unità in Esplora soluzioni.
    2. Aggiungi > Elemento esistente …
    3. Passare alla cartella dei pacchetti della soluzione e individuare la cartella del pacchetto net40 per Microsoft.Bcl ; ad esempio, … \ packages \ Microsoft.Bcl.1.1.10 \ lib \ net40 \
    4. Seleziona Tutti i file (*. *) Nel menu a discesa Tipo file.
    5. Tenendo premuto il tasto Ctrl , fare clic con il tasto sinistro del mouse su System.Runtime.dll e System.Threading.Tasks.dll per selezionarli.
    6. Fai clic sulla piccola freccia a discesa sul pulsante Aggiungi . (Non fare clic sul pulsante Aggiungi .)
    7. Nel menu a discesa Aggiungi , fai clic su Aggiungi come . Entrambi gli assembly sono ora visibili nella radice del progetto.
      • È necessario lasciare i collegamenti all’assembly nella radice del progetto. Non spostarli in una sottocartella.
      • Se il tuo progetto è sotto il controllo del codice sorgente, potresti notare che questi file collegati sono contrassegnati come esclusi (e se non lo sono, dovrebbero essere.) La cartella dei pacchetti NuGet, dove risiedono questi file, non dovrebbe essere controllata nel controllo del codice sorgente . Dal momento che sono solo file collegati, chiunque cancelli le tue modifiche non dovrebbe avere alcun problema dopo aver ripristinato i loro pacchetti NuGet.
  4. Selezionare entrambi i file di assiemi collegati in Esplora soluzioni ( Ctrl + clic sinistro) o eseguire semplicemente i seguenti passaggi su ciascun file separatamente.
  5. Fai clic con il pulsante destro del mouse su uno dei file selezionati e seleziona Proprietà . Si apre la finestra Proprietà .
  6. Impostare il campo Copia su directory di output su Copia se più recente .

Il tuo file di progetto di test dell’unità dovrebbe ora contenere qualcosa di simile al seguente.

   System.Runtime.dll PreserveNewest   System.Threading.Tasks.dll PreserveNewest   

E questo è tutto!

Tieni presente che il tuo progetto di test dell’unità ha come target .NET 4.5 (o una versione successiva, se lo desideri) e quindi i test di unità possono utilizzare metodi async e qualsiasi altra funzionalità di .NET 4.5. Non ci dovrebbero essere conflitti con gli assembly .NET 4.0 che stai testando, ma se trovi dei conflitti, è probabilmente perché hai ridefinito alcuni tipi per le nuove funzionalità di Framework / C # e li hai resi pubblici, causando conflitti quando tu provi a usare quegli stessi tipi nei tuoi test unitari. La soluzione migliore è semplicemente rendere tali tipi interni ai progetti che stai testando.

Modificare:
Dopo aver seguito questi passaggi, potresti ricevere alcuni avvisi di costruzione:

Tutti i progetti che fanno riferimento a My.csproj devono installare il pacchetto nuget Microsoft.Bcl.Build. Per ulteriori informazioni, vedere http://go.microsoft.com/fwlink/?LinkID=317569
{} Radice \ packages \ Microsoft.Bcl.Build.1.0.21 \ build \ Microsoft.Bcl.Build.targets

Per evitare questi avvertimenti, è sufficiente modificare il progetto di test unitario e aggiungere il seguente elemento metadati a ogni riferimento di progetto che punta a un progetto che fa riferimento a Microsoft.Bcl.Build .

 SkipValidatePackageReferences=true 

Per esempio:

  {664a9e98-fac7-4567-a046-0dde95fddb48} pcl SkipValidatePackageReferences=true  

La spiegazione completa può essere trovata nel file .targets indicato con il pacchetto Microsoft.Bcl.Build . Ecco il commento completo, per tua comodità.

BclBuildValidateNugetPackageReferences

Questo target convalida che tutti i pacchetti Nuget installati nel progetto corrente vengono installati anche nei progetti che fanno riferimento al progetto corrente.

Questo è necessario perché i pacchetti Nuget contengono più di semplici riferimenti. L’installazione del pacchetto garantisce
1. Viene aggiunta la giusta serie di riferimenti per il framework di destinazione
2. Vengono applicate le trasformazioni del file di configurazione
3. Gli script di installazione del progetto vengono eseguiti

Per tutti i pacchetti elencati come installati per il progetto corrente nella config dei pacchetti, se l’ID del pacchetto corrisponde a uno specificato in @ (ValidatePackages), assicurarsi che lo stesso pacchetto sia installato nel progetto di riferimento.

Questo target può essere disabilitato per un riferimento al progetto impostando SkipValidatePackageReferences = true per il riferimento:

  {664a9e98-fac7-4567-a046-0dde95fddb48} pcl SkipValidatePackageReferences=true  

Questo target può essere disabilitato per tutti i riferimenti a un progetto aggiungendo quanto segue:

  true