Domande frequenti su Live Unit Testing

Live Unit Testing è compatibile con i tre framework di testing unità elencati nella tabella riportata in seguito. Nella tabella è indicata anche la versione minima supportata degli adattatori e dei framework. I framework di unit test sono tutti disponibili su NuGet.org.

Se si hanno progetti di test basati su MSTest meno recenti che fanno riferimento 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.

Sì. Live Unit Testing funziona con .NET Core e .NET Framework.

La finestra Output (quando è selezionato l'elenco a discesa Live Unit Testing) indica perché Live Unit Testing non funziona. È possibile che Live Unit Testing non funzioni per uno dei motivi seguenti:

• Se i pacchetti NuGet a cui fanno riferimento i progetti nella soluzione non sono stati ripristinati, Live Unit Testing non funzionerà. Per risolvere questo problema, eseguire una compilazione esplicita della soluzione o ripristinare i pacchetti NuGet nella soluzione prima di attivare Live Unit Testing.

• Se nei progetti si usano test basati su MSTest, verificare di rimuovere il riferimento a Microsoft.VisualStudio.QualityTools.UnitTestFramework e aggiungere i riferimenti alle versioni più recenti dei pacchetti NuGet di MSTest, ovvero MSTest.TestAdapter (è richiesta almeno la versione 1.1.11) e MSTest.TestFramework (è richiesta almeno la versione 1.1.11). Per altre informazioni, vedere la sezione "Framework di test supportati" nell'articolo Usare Live Unit Testing in Visual Studio.

• Almeno un progetto della soluzione deve includere un riferimento a NuGet o un riferimento diretto al framework di test xUnit, NUnit o MSTest. Questo progetto deve anche fare riferimento a un pacchetto NuGet corrispondente degli adattatori di test di Visual Studio.

Gli errori di compilazione vengono segnalati alla finestra Output quando è selezionato l'elenco a discesa Live Unit Testing. Esistono alcuni problemi comuni causati da una configurazione errata nell'installazione guidata che possono causare problemi di compilazione in Live Unit Testing.

• Se la proprietà Root dell'area di lavoro è troppo lunga, è possibile che la compilazione non riesca a causa di eccezioni che indicano che il percorso è troppo lungo.

• Se la proprietà Radice repository non punta alla radice del repository, l'area di lavoro verrà popolata con il set di file errato.

• Per i repository Git, la proprietà Exclude files in genere evita di copiare i file specificati nel file gitignore . Tuttavia, è possibile archiviare i file nel repository Git ignorati oppure è possibile eseguire strumenti che generano automaticamente i file, ma non vengono generati durante la compilazione. In questi casi, è necessario scegliere l'opzione "<Personalizzato>" e un set personalizzato di regole che elencano solo le cartelle degli artefatti devono essere elencate.

Oltre ai problemi descritti in precedenza, le configurazioni di progetto seguenti che potrebbero non essere compilate correttamente.

• Se le dipendenze del progetto vengono specificate come configurazione della soluzione globale e non come ProjectReferences per ogni progetto, Live Unit Testing potrebbe terminare la compilazione del set di progetti non corretto. Per risolvere il problema, aggiungere riferimenti espliciti tra progetti.

• Finché non viene scelta una playlist di Live Unit Testing, Live Unit Testing non compilerà alcun progetto. Per risolvere questo problema, includere alcuni test nella playlist Live Unit Testing.

• Se si usano test basati su MSTest nei progetti, assicurarsi di rimuovere il riferimento a Microsoft.VisualStudio.QualityTools.UnitTestFrameworke aggiungere riferimenti ai pacchetti NuGet MSTest più recenti( MSTest.TestAdapter è necessaria una versione minima di 1.1.11) e MSTest.TestFramework (è necessaria una versione minima di 1.1.11). Per altre informazioni, vedere Framework di test supportati.

• Almeno un progetto della soluzione deve includere un riferimento a NuGet o un riferimento diretto al framework di test xUnit, NUnit o MSTest. Questo progetto deve anche fare riferimento a un pacchetto NuGet corrispondente degli adattatori di test di Visual Studio. È anche possibile usare un file con estensione runsettings per fare riferimento all'adattatore di test di Visual Studio. Il file con estensione runsettings deve contenere una voce simile a quella dell'esempio seguente:

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

• Un problema comune è che non tutti i file vengono copiati nella cartella di test. Potrebbe essere necessario aggiungere alcuni elementi di dipendenza di Live Unit Testing ai file csproj .

• Un altro problema è il timeout. Poiché Live Unit Testing esegue test a tempo indeterminato, interrompe automaticamente un'esecuzione se i test vengono eseguiti per troppo tempo. È possibile aumentare il timeout nella procedura guidata del progetto.

• Se più progetti nella soluzione fanno riferimento al pacchetto dell'adattatore di test NuGet, è necessario aggiornare ogni progetto alla versione supportata.

• Assicurarsi che anche il file MSBuild con estensione props importato dal pacchetto dell'adattatore di test sia stato aggiornato correttamente. Controllare la versione o il percorso del pacchetto NuGet importato indicato in genere nella parte superiore del file di progetto, come illustrato di seguito:

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Se la soluzione richiede passaggi personalizzati per la compilazione per la strumentazione (Live Unit Testing) che non sono necessari per la compilazione non instrumentata "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. È anche possibile scegliere di rimuovere alcune istruzioni di compilazione, ad esempio per la pubblicazione o la creazione di pacchetti, o di aggiungere istruzioni di compilazione, ad esempio per la copia dei prerequisiti, a una compilazione di Live Unit Testing in base a questa proprietà del progetto. La personalizzazione della compilazione basata su questa proprietà non modifica in alcun modo la compilazione regolare e influisce solo sulle compilazioni di Live Unit Testing.

Ad esempio, potrebbe essere presente una destinazione che produce pacchetti NuGet durante una compilazione normale. È probabile che non si vogliano generare pacchetti NuGet dopo ogni modifica apportata. È quindi possibile disabilitare tale destinazione nella compilazione Live Unit Testing eseguendo un'operazione simile alla seguente:

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

Esistono numerose differenze:

• Durante l'esecuzione o il debug di test nella finestra Esplora test vengono eseguiti file binari normali, mentre con Live Unit Testing vengono eseguiti file instrumentati. Se si vuole eseguire il debug di file binari instrumentati, provare ad aggiungere una chiamata al metodo Debugger.Launch nel metodo di test per fare in modo che il debugger venga avviato ogni volta che si esegue tale metodo (incluso quando viene eseguito da Live Unit Testing). A questo punto è possibile collegare ed eseguire il debug del file binario instrumentato. Tuttavia, speriamo che la strumentazione sia trasparente per la maggior parte degli scenari utente e che non sia necessario eseguire il debug dei file binari instrumentati.

• Live Unit Testing non crea un nuovo dominio applicazione per eseguire i test, ma i test eseguiti dalla finestra Esplora test creano un nuovo dominio applicazione.

• Live Unit Testing esegue i test di ogni assembly di test in modo sequenziale. In Esplora test è possibile scegliere di eseguire più test in parallelo.

• Esplora test esegue test in un apartment a thread singolo (STA) per impostazione predefinita, mentre Live Unit Testing esegue test in un apartment a thread multipli (MTA). Per eseguire test MSTest nell'apartment a thread singolo in Live Unit Testing, decorare il metodo di test o la classe contenitore con l'attributo <STATestMethod> o <STATestClass> reperibili nel pacchetto NuGet MSTest.STAExtensions 1.0.3-beta. Per NUnit e xUnit decorare il metodo di test rispettivamente con l'attributo <RequiresThread(ApartmentState.STA)> e con l'attributo <STAFact>.

Per l'impostazione specifica dell'utente, vedere la sezione "Inclusione ed esclusione di progetti e metodi di test" dell'articolo Usare Live Unit Testing in Visual Studio. L'inclusione o l'esclusione di test è utile quando si vuole eseguire un set specifico di test per una determinata sessione di modifica oppure per rendere persistenti le proprie preferenze personali.

Per le impostazioni specifiche della soluzione è possibile applicare l'attributo System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute a livello di codice per evitare che metodi, proprietà, classi o strutture vengano instrumentati da Live Unit Testing. È anche possibile impostare la proprietà <ExcludeFromCodeCoverage> su true nel file di progetto per evitare che l'intero progetto venga instrumentato. Live Unit Testing eseguirà comunque i test che non sono stati instrumentati, ma la relativa copertura non verrà visualizzata.

È anche possibile verificare se Microsoft.CodeAnalysis.LiveUnitTesting.Runtime è caricato nel dominio applicazione corrente e disabilitare i test sulla base del motivo corrispondente. Ad esempio, è possibile eseguire quanto segue con xUnit:

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

La soluzione può essere compilata anche se non si apportano modifiche se il processo di compilazione genera codice sorgente che fa parte della soluzione stessa e i file di destinazione della compilazione non hanno input e output appropriati specificati. È necessario specificare un elenco di input e di output per le destinazioni in modo che MSBuild possa eseguire i controlli di aggiornamento appropriati e stabilire se è necessaria una nuova compilazione.

Live Unit Testing avvia una compilazione ogni volta che rileva una modifica nei file di origine. Poiché la compilazione della soluzione genera file di origine, Live Unit Testing entra in un ciclo di compilazione infinito. Se, tuttavia, gli input e gli output della destinazione vengono controllati quando Live Unit Testing avvia la seconda compilazione (dopo aver rilevato i file di origine appena generati dalla build precedente), si interrompe il ciclo di compilazione perché i controlli di input e output indicano che tutto è aggiornato.

Questa situazione si verifica se gli assembly su cui Live Unit Testing è in esecuzione non sono instrumentati per un qualsiasi motivo. Ad esempio, Live Unit Testing non è compatibile con i progetti che impostano <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. In questo caso, è necessario aggiornare il processo di compilazione in modo da rimuovere questa impostazione o modificarla in true per consentire il corretto funzionamento di Live Unit Testing. 

Per raccogliere log più dettagliati, è possibile eseguire diverse operazioni:

• Passare a Strumenti>Opzioni>Live Unit Testing e impostare l'opzione del livello di registrazione su Dettagliato, in modo che vengano visualizzati log più dettagliati nella finestra di output.

• Impostare la variabile di ambiente utente LiveUnitTesting_BuildLog sul nome del file da usare per acquisire il log di MSBuild. Sarà quindi possibile recuperare da tale file i messaggi dettagliati del log di MSBuild restituiti da compilazioni di Live Unit Testing.

• Impostare la variabile di ambiente utente LiveUnitTesting_TestPlatformLog su 1 per acquisire il log della piattaforma di test. Sarà quindi possibile recuperare i messaggi dettagliati del log della piattaforma di test generati dalle esecuzioni di Live Unit Testing da [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID].

• Creare una variabile di ambiente a livello di utente denominata VS_UTE_DIAGNOSTICS e impostarla su 1 (o su un valore qualsiasi) e quindi riavviare Visual Studio. A questo punto verranno visualizzati molti più messaggi di registrazione nella scheda Output - Test di Visual Studio.

No, non è consigliabile aprire o modificare i file nelle directory di compilazione e test della cartella dell'area di lavoro. Live Unit Testing deve gestire tutti i file nella cartella src, per mantenerli sincronizzati tra la radice del repository e la radice dell'area di lavoro.

Sì, ma è necessario assicurarsi che sia abilitato. Se si usa un'unità di sviluppo, assicurarsi che il filtro ProjFS (Projected File System) sia abilitato. Ad esempio, il comando seguente abilita ProjFS e Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt, WdFilter

Vedi anche

• Live Unit Testing