Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 funziona con i tre framework di unit test più diffusi elencati nella tabella seguente. Viene visualizzata anche la versione minima supportata degli adattatori e dei framework. I framework di unit test sono tutti disponibili da 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>Ricostruisci soluzione nel menu principale 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 la procedura guidata di configurazione 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 del workspace potrebbe essere modificata a qualcosa come 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 .
Annotazioni
Per alcuni repository Git è necessario un file lutignore personalizzato, perché è possibile registrare dei 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 Opzioni espandere la sezione Tutte le impostazioni>Test>live unit testing .
Nella finestra di dialogo Opzioni, espandere la sezione Generale di Test delle Unità Live.
Dopo l'abilitazione di Live Unit Testing (vedere Avvio, sospensione e arresto di Live Unit Testing), è possibile aprire di nuovo le opzioni selezionando Test>Live Unit Testing>Opzioni.
Le opzioni configurabili includono:
Indica se Live Unit Testing viene sospeso quando viene compilata e sottoposta a debug una soluzione.
Indica se Live Unit Testing viene sospeso quando l'alimentazione della batteria di un sistema scende al di sotto di 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 di informazioni scritte nella finestra Output di Live Unit Testing.
Le opzioni includono nessun log (Nessuno), solo messaggi di Errore (Errore), messaggi di Errore e Informazione (Info, impostazione predefinita) o tutti i dettagli (Verboso).
È 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 messaggi di log dettagliati di MSBuild da Live Unit Testing in un file, impostare la
LiveUnitTesting_BuildLogvariabile di ambiente a livello di utente sul nome del file in modo che contenga il log.
Personalizza la build 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 override 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, Live Unit Testing imposta <RunAnalyzers>false</RunAnalyzers> per disabilitare gli analizzatori dei test.
Dipendenze dei 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.
Annotazioni
Le dipendenze di test devono esistere all'interno della directory specificata come Radice del repository nella procedura guidata di configurazione.
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 file sorgente o la console_utility alla cartella di test, inserisci il seguente esempio in test_project.csproj:
<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Src/ConsoleUtility” />
<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Artifacts/ConsoleUtility/net472/$(Configuration)/</LiveUnitTestingTestDependency” />
Avvia, sospendi e arresta
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 e 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.
Ferma 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...".
In qualsiasi momento, è possibile sospendere temporaneamente o arrestare completamente Live Unit Testing. È 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 di test 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. Ad esempio, se si dispone di una soluzione con centinaia di progetti di test, è possibile selezionare un set di progetti di test di destinazione per partecipare a 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
- Programmaticamente nel 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 dello strumento 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 verifica un singolo test, Live Unit Testing lo esegue su 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
È possibile usare la finestra dell'editor di codice per includere o escludere singoli metodi di test. 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>Includi <metodo> selezionato
- Live Unit Testing>Escludi <metodo> selezionato
- Live Unit Testing>Escludi tutto ma <metodo selezionato>
Esplora soluzioni
Per selezionare i singoli progetti negli unit test, seguire questa procedura dopo l'avvio di Live Unit Testing:
- Fare clic con il pulsante destro del mouse sulla soluzione in Esplora soluzioni e selezionare Live Unit Testing>Exclude per escludere l'intera soluzione.
- Fare clic con il pulsante destro del mouse su ciascun progetto di test da includere e selezionare Live Unit Testing>Include.
Programmaticamente nel codice di test
È possibile applicare l'attributo ExcludeFromCodeCoverageAttribute a metodi, classi o strutture per escluderli programmaticamente dalla segnalazione della copertura 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 righe con un "✓" verde sono coperte esclusivamente superando 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 segnalare che i dati non sono aggiornati, aggiungendo sotto i simboli di superamento, errore e copertura mancata un'immagine di timer circolare, come illustrato nell'immagine sottostante.
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, il tooltip consente di rieseguire o fare il debug del set di test. Se si seleziona uno o più test nel suggerimento, è possibile eseguire o effettuare il debug solo di quei 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 andare direttamente a un test non riuscito, fare doppio clic sul suggerimento.
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 inclusi in Live Unit Testing (indicato da un bicchiere 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 e fare il debug dei test e 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 utilizzando Visualizza>Altre finestre>Finestra di 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 sfumati indicano che il test non faceva 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 qualsiasi test che appaiono sbiaditi apportando una modifica al codice.
Esistono alcune differenze tra il Live Unit Testing che esegue e aggiorna automaticamente i risultati dei test e l'esecuzione esplicita dei test da Esplora test. Queste differenze includono:
- L'esecuzione o il debug dei test dalla finestra Esplora test esegue file binari ordinari. 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. I test eseguiti dalla finestra Esplora test creano un nuovo dominio applicazione.
- Live Unit Testing esegue i test in sequenza per ogni assembly. 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.