Configurare e usare Live Unit Testing

Durante lo sviluppo di un'applicazione, Live Unit Testing esegue automaticamente gli unit test interessati in background e presenta i risultati e il code coverage in tempo reale. Quando si modifica il codice, Live Unit Testing fornisce feedback su come le modifiche hanno interessato i test esistenti e se il nuovo codice aggiunto è coperto da uno o più test esistenti. Questo feedback ricorda di scrivere unit test durante la correzione di bug o l'aggiunta di nuove funzionalità.

Quando si usa Live Unit Testing per i test, i dati vengono mantenuti sullo stato dei test. L'uso di dati persistenti consente a Live Unit Testing di offrire prestazioni superiori durante l'esecuzione dinamica dei test in risposta alle modifiche al codice.

Live Unit Testing è disponibile solo nell'edizione Enterprise di Visual Studio per i progetti destinati a .NET Core o .NET Framework.

Framework di test supportati

Live Unit Testing è compatibile con i tre framework di unit test elencati nella tabella seguente. Viene visualizzata anche la versione minima supportata degli adattatori e dei framework. I framework di unit test sono tutti disponibili su NuGet.org.

Framework di test	Versione minima dell'adapter di Visual Studio	Versione minima del framework
xUnit.net	xunit.runner.visualstudio versione 2.2.0-beta3-build1187	xunit 1.9.2
NUnit	NUnit3TestAdapter versione 3.5.1	NUnit versione 3.5.0
MSTest	MSTest.TestAdapter 1.1.4-preview	MSTest.TestFramework 1.0.5-preview

Se sono presenti progetti di test basati su MSTest meno recenti che fanno riferimento a Microsoft.VisualStudio.QualityTools.UnitTestFramework e non si vuole passare ai pacchetti NuGet MSTest più recenti, eseguire l'aggiornamento a Visual Studio 2019 o Visual Studio 2017.

In alcuni casi, potrebbe essere necessario ripristinare in modo esplicito i pacchetti NuGet a cui fa riferimento un progetto per il funzionamento di Live Unit Testing. è possibile procedere in due modi:

• Eseguire il ripristino eseguendo una compilazione esplicita della soluzione. Selezionare Compila ricompila>soluzione nel menu di primo livello di Visual Studio.
• Ripristinare i pacchetti nella soluzione. Fare clic con il pulsante destro del mouse sulla soluzione e scegliere Ripristina pacchetti NuGet.

Configurare

La prima volta che si avvia Live Unit Testing per una soluzione, una procedura guidata di installazione consente di configurare il modo in cui Live Unit Testing deve compilare ed eseguire test.

Quando Live Unit Testing viene arrestato, è anche possibile aprire l'installazione guidata passando a Test>Live Unit Testing Configura Live Unit Testing>per la soluzione.

Durante l'esecuzione di Live Unit Testing, viene creata un'area di lavoro, ovvero una copia del repository originale. Live Unit Testing applica quindi tutte le modifiche non salvate apportate in Visual Studio all'area di lavoro, esegue una compilazione, esegue un'esecuzione di test e segnala la code coverage più recente.

La prima cosa da configurare tramite la procedura guidata è la posizione da cui copiare i file e dove devono essere copiati.

Radice del repository

La radice del repository specifica la cartella che verrà copiata per creare l'area di lavoro Live Unit Testing. Deve essere la cartella radice del repository, ovvero deve contenere tutte le origini, i file binari e gli strumenti. Nei casi in cui il file della soluzione non è presente nella radice del repository, potrebbe essere necessario modificare la radice del repository.

Radice dell'area di lavoro

La radice dell'area di lavoro specifica la cartella in cui Live Unit Testing mantiene un clone del repository. Prestare attenzione alle eccezioni che indicano che il percorso è troppo lungo. Per impostazione predefinita, la radice viene creata nella home cartella. Tuttavia, ad esempio, se in genere è necessario creare il repository nell'unità C, la radice dell'area di lavoro potrebbe essere modificata in modo analogo a C:\lut\Repo.

Specificare i file esclusi

Non tutti i file devono essere copiati nell'area di lavoro Live Unit Testing. Tutti gli artefatti generati durante la compilazione devono essere esclusi dalla copia in modo che le compilazioni regolari non interferiscano con le compilazioni di Live Unit Testing. Inoltre, il comando normale nuget restore non deve interferire con il comando Live Unit Testing nuget restore .

Per impostazione predefinita, Live Unit Testing esclude uno dei due modelli di file:

• Per i repository Git, i file specificati nel file gitignore non vengono copiati nell'area di lavoro Live Unit Testing.
• Per i repository non Git, un elenco di base di cartelle, ad esempio bin/ e obj/, non viene copiato nell'area di lavoro Live Unit Testing.

Per i repository più complessi, potrebbe essere necessario specificare il proprio file ignore. Selezionare l'opzione "<Personalizzata>" dalla procedura guidata. Dopo aver selezionato Avanti, il contenuto di un file personalizzato ignorato creato da Live Unit Testing al termine della procedura guidata viene visualizzato. È il file lutignore .

Nota

Per alcuni repository Git è necessario un file lutignore personalizzato perché è possibile archiviare i file nel repository Git che vengono ignorati anche dal file gitignore. Senza un file lutignore personalizzato, Live Unit Testing non copia questi file, che potrebbero causare errori di compilazione.

Struttura di file Lutignore

Il file lutignore usa lo stesso formato di un file gitignore . Deve contenere regole che corrispondono alle cartelle o ai file generati durante la compilazione in modo che non vengano copiati nell'area di lavoro. Per la maggior parte dei modelli di progetto predefiniti, il file ignore seguente è sufficiente:

[BB]IN
[OO]BJ
# WILL NOT COPY ANY BIN AND OBJ FOLDERS TO THE LIVE UNIT TESTING WORKSPACE

Se il repository ha una singola cartella di compilazione, il file ignore deve invece elencare tale cartella:

[AA]RTIFACTS/
# WILL NOT COPY THE ARTIFACTS FOLDER TO THE LIVE UNIT TESTING WORKSPACE

Se il repository include altri strumenti nella cartella di compilazione, questi strumenti devono essere esclusi nel set di modelli di corrispondenza:

[AA]RTIFACTS/
![AA]RTIFACTS/TOOLS/
# WILL NOT COPY THE ARTIFACTS FOLDER TO THE LIVE UNIT TESTING WORKSPACE
# HOWEVER IT WILL COPY THE TOOLS SUBFOLDER THAT MIGHT CONTAIN TOOLS AND UTILITIES

Opzioni di compilazione

La seconda parte della pagina di configurazione della procedura guidata è la posizione in cui si configurano le opzioni di compilazione:

• Generare PDB: per velocizzare la compilazione, Live Unit Testing non genera PDB durante le compilazioni. Questi file di simboli consentono di passare alle analisi dello stack quando si verificano errori di test.
• Compilazione con più core CPU: per impostazione predefinita, Live Unit Testing esegue compilazioni usando più core CPU, migliorando i tempi di compilazione. Se il computer rallenta o se la soluzione non riesce a essere compilata usando più processori, non selezionare questa opzione.

Opzioni di esecuzione dei test

L'ultima parte della pagina di configurazione della procedura guidata è la posizione in cui sono state configurate le opzioni di esecuzione dei test:

• Timeout del test case: l'esecuzione di alcuni test potrebbe richiedere molto tempo. L'impostazione di questo campo interrompe automaticamente l'esecuzione se uno dei test supera una durata specifica. I test possono essere annullati automaticamente.
• Usare più processori: per impostazione predefinita, Live Unit Testing prova a usare più processori per velocizzare le prestazioni di esecuzione. Se il computer rallenta o se la soluzione non è in grado di eseguire test in parallelo, non selezionare questa opzione. Ad esempio, questi scenari possono verificarsi se più test tentano di scrivere/leggere dagli stessi percorsi di file.

Altre configurazioni

Configurare Live Unit Testing selezionando Strumenti>Opzioni nella barra dei menu di primo livello di Visual Studio. Nel riquadro sinistro della finestra di dialogo Opzioni selezionare Live Unit Testing.

Dopo l'abilitazione di Live Unit Testing (vedere Avvio, sospensione e arresto di Live Unit Testing), è anche possibile aprire la finestra di dialogo Opzioni selezionando Test>opzioni di Live Unit Testing.>

L'immagine seguente mostra le opzioni di configurazione di Live Unit Testing disponibili nella finestra di dialogo.

Le opzioni configurabili includono:

• Sospensione dell'esecuzione di Live Unit Testing in caso di compilazione e debug di una soluzione.

• Sospensione dell'esecuzione di Live Unit Testing quando l'alimentazione a batteria del sistema scende sotto una soglia specificata.

• Possibilità di eliminare tutti i dati persistenti. Questa funzionalità è utile quando Live Unit Testing si comporta in modo imprevedibile o imprevisto, che suggerisce che i dati persistenti sono danneggiati.

• Quantità massima di memoria che i processi di Live Unit Testing possono utilizzare.

• Livello delle informazioni scritte nella finestra Output di Live Unit Testing.

  È possibile scegliere di non visualizzare informazioni di log (Nessuno), solo i messaggi errore (Errore), messaggi di errore e messaggi informativi (Informazioni, che corrisponde al valore predefinito) o tutti i dettagli (Dettagliato).

  È anche possibile visualizzare l'output dettagliato nella finestra Output di Live Unit Testing assegnando un valore 1 a una variabile di ambiente a livello di utente denominata VS_UTE_DIAGNOSTICS. Riavviare quindi Visual Studio.

  Per acquisire in un file i messaggi di log dettagliati di MSBuild restituiti da Live Unit Testing, impostare la variabile di ambiente a livello di utente LiveUnitTesting_BuildLog sul nome del file in cui salvare il log.

Personalizzare la compilazione per Live Unit Testing

Per soluzioni più complesse, potrebbe essere necessario personalizzare ulteriormente la compilazione. Ad esempio, potrebbe non essere necessario compilare file di traduzione durante l'esecuzione dei test. Per velocizzare le compilazioni, è possibile disabilitare la compilazione del file di traduzione con Live Unit Testing. A tale scopo, è possibile modificare i file di progetto.

Aggiungere sostituzioni di Live Unit Testing

Se la soluzione richiede passaggi personalizzati per la compilazione per la strumentazione (Live Unit Testing) che non sono necessari per la compilazione non strumentata "regolare", è possibile aggiungere codice ai file di progetto o con estensione targets che controllano la BuildingForLiveUnitTesting proprietà ed eseguono passaggi di pre/post compilazione personalizzati.

Ad esempio, è possibile scrivere l'esempio seguente per aggiungere un'altra destinazione eseguita solo per Live Unit Testing:

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' == 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

È possibile usare la BuildingForLiveUnitTesting proprietà per disabilitare alcune attività che non devono essere eseguite per le compilazioni di test. Ad esempio, i set <RunAnalyzers>false</RunAnalyzers> di Live Unit Testing per disabilitare gli analizzatori per i test.

Dipendenze di test di Live Unit Testing

È possibile che non tutti i file siano stati copiati necessari per l'esecuzione dei test. Live Unit Testing crea una cartella separata in cui esegue i test. Tale disposizione consente la compilazione durante l'esecuzione dei test, ma non tutti i file della cartella di compilazione vengono copiati nella cartella di test.

In genere, si aggiungono le dipendenze di test per uno dei due motivi seguenti:

• I test dipendono dai file nell'albero di origine. Ad esempio, i test esaminano il contenuto dei file resx o potrebbero leggere alcuni file di configurazione.
• I test dipendono da alcune librerie a cui fanno riferimento. Ad esempio, un test esegue un eseguibile compilato come dipendenza.

Nota

Le dipendenze di test devono esistere all'interno della directory specificata come Radice repository nella configurazione guidata.

In entrambi i casi, Live Unit Testing per impostazione predefinita non copia questi file allo scopo di ridurre al minimo il numero di file che devono essere copiati per eseguire un test. È necessario specificare in modo esplicito questi file usando la LiveUnitTestingTestDependency proprietà se sono necessari per un'esecuzione di test. Si supponga, ad esempio, di avere il layout seguente:

SRC/
  CONSOLE_UTILITY/
  TEST_PROJECT/
ARTIFACTS/
  CONSOLE_UTILITY/NET472/DEBUG/
  TEST_PROJECT/NET472/DEBUG/

Per impostazione predefinita, quando si compilano questi progetti con Live Unit Testing, vengono copiati Artifacts/Test_Project solo nella cartella di test. Per aggiungere origini o il console_utility alla cartella di test, aggiungere l'esempio seguente a test_project.csproj:

<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Src/ConsoleUtility” />
<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Artifacts/ConsoleUtility/net472/$(Configuration)/</LiveUnitTestingTestDependency” />

Avviare, sospendere e arrestare

Per abilitare Live Unit Testing, selezionare Test>Live Unit Testing>Start nel menu di primo livello di Visual Studio. Quando Live Unit Testing è abilitato, le opzioni disponibili nel menu Live Unit Testing cambiano da un singolo elemento, Start, a Pause and Stop:When Live Unit Testing is enabled, the options available on the Live Unit Testing menu change from a single item, Start, to Pause and Stop:

• Sospende temporaneamente Live Unit Testing.

  Quando Live Unit Testing viene sospeso, la visualizzazione della copertura non viene visualizzata nell'editor, ma tutti i dati raccolti vengono mantenuti. Per riprendere Live Unit Testing, selezionare Continua dal menu Live Unit Testing . Live Unit Testing esegue il lavoro necessario per recuperare tutte le modifiche apportate durante la sospensione e aggiorna i glifi in modo appropriato.

• L'arresto arresta completamente Live Unit Testing. Live Unit Testing elimina tutti i dati raccolti.

Se si avvia Live Unit Testing in una soluzione che non include un progetto di unit test, le opzioni Sospendi e Arresta vengono visualizzate nel menu Live Unit Testing , ma Live Unit Testing non viene avviato. Nella finestra Output viene visualizzato un messaggio che inizia, "Nessun adattatore di test supportato fa riferimento a questa soluzione...".

È possibile sospendere temporaneamente o arrestare completamente Live Unit Testing in qualsiasi momento. È possibile eseguire queste azioni, ad esempio, se ci si trova al centro del refactoring e si sa che i test verranno interrotti per un po'.

Includere ed escludere progetti e metodi di test

Quando si avvia Live Unit Testing, viene visualizzata la finestra degli strumenti Live Unit Testing e viene richiesto di selezionare il set di test da testare da Live Unit Testing.

Per soluzioni più piccole in cui l'esecuzione degli unit test richiede molto poco tempo, selezionare Includi tutti i test, che rende Live Unit Testing eseguire tutti i test.

Per soluzioni di grandi dimensioni con molti progetti di test, è possibile controllare quali progetti e singoli metodi in un progetto partecipano a Live Unit Testing modificando la playlist. Se ad esempio una soluzione contiene centinaia di progetti di test, è possibile selezionare un set specifico di progetti di test da includere in Live Unit Testing.

È possibile scegliere l'esecuzione di Live Unit Testing modificando una playlist di Live Unit Testing, una funzionalità che funziona esattamente come le playlist in Esplora test.

Esistono diversi modi per modificare la playlist di Live Unit Testing:

• Finestra degli strumenti Live Unit Testing
• Finestra dell'editor di codice
• Esplora soluzioni
• A livello di codice di test

Live Unit Testing salva lo stato di inclusione/esclusione come impostazione utente e lo memorizza quando una soluzione viene chiusa e riaperta.

Finestra degli strumenti Live Unit Testing

È possibile usare l'editor di playlist per la scheda Live Unit Testing per includere o escludere progetti, spazi dei nomi o classi dall'esecuzione. Selezionare Modifica playlist nella finestra degli strumenti.

È possibile selezionare o deselezionare gli elementi della visualizzazione albero per includere o escludere test. Ad esempio, se si controlla un singolo test, Live Unit Testing lo esegue alle modifiche. Se si seleziona una classe, vengono eseguiti tutti i test della classe e tutti i nuovi test aggiunti a tale classe vengono eseguiti.

Finestra dell'editor di codice

Per includere o escludere singoli metodi di test, è possibile usare la finestra dell'editor del codice. Fare clic con il pulsante destro del mouse sulla firma o sul corpo del metodo di test nella finestra dell'editor di codice e selezionare una delle opzioni seguenti:

• Live Unit Testing>Include <selected method>
• Live Unit Testing>Exclude <selected method>
• Live Unit Testing>Exclude All But <selected method>

Esplora soluzioni

Per selezionare i singoli progetti negli unit test, seguire questa procedura dopo l'avvio di Live Unit Testing:

1. Fare clic con il pulsante destro del mouse sulla soluzione in Esplora soluzioni e selezionare Live Unit Testing Exclude (Escludi live unit testing>) per escludere l'intera soluzione.
2. Fare clic con il pulsante destro del mouse su ogni progetto di test che si vuole includere nei test e selezionare Live Unit Testing Include (Includi live unit testing>).

A livello di codice di test

È possibile applicare l'attributo ExcludeFromCodeCoverageAttribute per evitare a livello di codice che metodi, classi o strutture restituiscano informazioni sul code coverage in Live Unit Testing.

Usare gli attributi seguenti per escludere singoli metodi da Live Unit Testing:

• xUnit: [Trait("Category", "SkipWhenLiveUnitTesting")]
• NUnit: [Category("SkipWhenLiveUnitTesting")]
• MSTest: [TestCategory("SkipWhenLiveUnitTesting")]

Usare gli attributi seguenti per escludere un intero assembly di test da Live Unit Testing:

• xUnit: [assembly: AssemblyTrait("Category", "SkipWhenLiveUnitTesting")]
• NUnit: [assembly: Category("SkipWhenLiveUnitTesting")]
• MSTest: [assembly: TestCategory("SkipWhenLiveUnitTesting")]

Visualizzare la visualizzazione della copertura

Dopo l'abilitazione di Live Unit Testing, aggiorna ogni riga di codice nell'editor di Visual Studio per indicare se il codice scritto è coperto dagli unit test e se i test che lo coprono vengono superati.

L'immagine seguente mostra righe di codice con test superati e non superati e righe di codice non coperte dai test. Le linee con un verde "✓" sono coperte solo passando i test. Le linee con una "x" rossa sono coperte da uno o più test non superati. Le linee con "" blu ➖ non sono coperte da alcun test.

La visualizzazione della copertura di Live Unit Testing viene aggiornata immediatamente quando si modifica il codice nell'editor di codice. Durante l'elaborazione delle modifiche, la visualizzazione cambia per indicare che i dati non sono aggiornati aggiungendo un'immagine timer rotonda sotto i simboli passati, non riusciti e non coperti, come illustrato nell'immagine seguente.

Ottenere informazioni sullo stato dei test

Passando il puntatore del mouse sul simbolo superato o non riuscito nella finestra del codice, è possibile visualizzare il numero di test che stanno raggiungendo tale riga. Per visualizzare lo stato dei singoli test, selezionare il simbolo.

Oltre a fornire i nomi e i risultati dei test, la descrizione comando consente di rieseguire o eseguire il debug del set di test. Se si seleziona uno o più test nella descrizione comando, è anche possibile eseguire o eseguire il debug solo di tali test. Questa azione consente di eseguire il debug dei test senza dover uscire dalla finestra del codice.

Quando si esegue il debug, oltre a osservare eventuali punti di interruzione già impostati, l'esecuzione del programma viene sospesa quando il debugger esegue un Assert metodo che restituisce un risultato imprevisto.

Quando si passa il puntatore del mouse su un test non riuscito nella descrizione comando, si espande per fornire altre informazioni sull'errore, come illustrato nell'immagine seguente. Per passare direttamente a un test non riuscito, fare doppio clic sulla descrizione comando.

Quando si passa al test non riuscito, Live Unit Testing indica visivamente nella firma del metodo i test con:

• Passato (indicato da un beaker mezzo pieno insieme a un verde "✓").
• Non riuscito (indicato da un beaker mezzo pieno insieme a un rosso "🞩").
• Non sono coinvolti in Live Unit Testing (indicato da un beaker mezzo pieno insieme a un blu "➖").

I metodi non di test non sono identificati con un simbolo. L'immagine seguente illustra tutti e quattro i tipi di metodi.

Diagnosticare e correggere gli errori di test

Dal test non riuscito è possibile eseguire facilmente il debug del codice prodotto, apportare modifiche e continuare a sviluppare l'applicazione. Poiché Live Unit Testing viene eseguito in background, non è necessario arrestare e riavviare Live Unit Testing durante il debug, la modifica e il ciclo di continuazione.

Ad esempio, l'errore di test mostrato nell'immagine precedente è stato causato da un presupposto non corretto nel metodo di test che i caratteri nonhabetici restituiscono true quando vengono passati al System.Char.IsLower metodo . Dopo aver corretto il metodo di test, tutti i test devono essere superati. Non è necessario sospendere o arrestare Live Unit Testing.

Finestra Live Unit Testing

Live Unit Testing, simile a Esplora test, offre un'interfaccia che consente di eseguire ed eseguire test ed analizzare i risultati dei test. Quando Live Unit Testing è abilitato, lo stato degli unit test in Esplora test viene aggiornato immediatamente. Non è necessario eseguire in modo esplicito gli unit test.

Quando Live Unit Testing non è abilitato o viene arrestato, Live Unit Testing visualizza lo stato degli unit test l'ultima volta che è stato eseguito un test. Dopo il riavvio di Live Unit Testing, è necessaria una modifica del codice sorgente per rieseguire i test.

È possibile avviare Live Unit Testing selezionando Test>Live Unit Testing>Start nel menu di primo livello di Visual Studio. È anche possibile aprire la finestra Live Unit Testing usando Visualizza>altra>finestra windows Live Unit Testing.

È possibile notare nella finestra Live Unit Testing che alcuni test vengono disattivati. Ad esempio, quando si arresta e si riavvia Live Unit Testing, la finestra Live Unit Testing svanisce tutti i test, come illustrato nell'immagine seguente.

I risultati dei test non superati indicano che il test non fa parte dell'ultima esecuzione di Live Unit Test. I test vengono eseguiti solo quando viene rilevata una modifica al test o le dipendenze del test. Se non è presente alcuna modifica, evita l'esecuzione inutilmente del test. In questo caso, il risultato del test in grigio è ancora "aggiornato", anche se non fa parte dell'esecuzione più recente.

È possibile rieseguire tutti i test visualizzati sbiaditi apportando una modifica al codice.

Esistono alcune differenze tra l'esecuzione automatica di Live Unit Testing e l'aggiornamento dei risultati dei test e l'esecuzione esplicita di test da Esplora test. Queste differenze includono:

• L'esecuzione o il debug di test dalla finestra Esplora test esegue normali file binari. Live Unit Testing esegue file binari instrumentati.
• Live Unit Testing non crea un nuovo dominio applicazione per l'esecuzione dei test. Esegue invece i test dal dominio predefinito. Quando i test vengono eseguiti dalla finestra Esplora test, viene invece creato un nuovo dominio applicazione.
• Live Unit Testing esegue i test di ogni assembly di test in modo sequenziale. Nella finestra Esplora test è possibile scegliere di eseguire più test in parallelo.

Annullare le esecuzioni di test di Live Unit Testing

Live Unit Testing continua a eseguire i test ogni volta che si apportano modifiche al codice. Se un'esecuzione è in corso e si apportano altre modifiche al codice, Live Unit Testing accoda un'altra esecuzione mentre attende il completamento della prima esecuzione.

Ogni volta che si salvano file, Live Unit Testing annulla la prima esecuzione e pianifica immediatamente l'esecuzione in coda. Questo processo è utile per gli scenari in cui la prima esecuzione avrebbe richiesto molto tempo per il completamento.

Vedi anche

• Strumenti di test del codice
• Blog di Live Unit Testing
• Domande frequenti su Live Unit Testing