Domande frequenti su Live Unit Testing

Live Unit Testing funziona con i tre framework di unit test più diffusi elencati nella tabella seguente. Nella tabella è elencata anche la versione minima supportata degli adattatori e dei framework. I framework di unit test sono tutti disponibili da NuGet.org.

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.

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. Live Unit Testing potrebbe non funzionare 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 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 la sezione "Framework di test supportati" dell'articolo Usare Live Unit Testing in Visual Studio.

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

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 nella configurazione guidata che possono causare problemi di compilazione in Live Unit Testing.

• Se la proprietà radice 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 del 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, è consigliabile scegliere l'opzione "<custom>" e un set personalizzato di regole che elencano solo le cartelle degli artefatti devono essere elencati.

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 Live Unit Testing, Live Unit Testing non creerà 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 nella soluzione deve avere un riferimento NuGet o un riferimento diretto al framework di test xUnit, NUnit o MSTest. Questo progetto deve anche fare riferimento a un pacchetto NuGet degli adattatori di test di Visual Studio corrispondente. È anche possibile fare riferimento all'adattatore di test di Visual Studio tramite un file runsettings. Il file .runsettings deve avere una voce simile all'esempio seguente:

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

Live Unit Testing non può compilare i progetti generatori di origine con la strumentazione. A causa del modo in cui il compilatore C# configura il caricamento degli assembly per i generatori di origine, il tentativo di compilare progetti generatori di origine con la strumentazione non riesce a caricare gli assembly di Live Unit Testing.

È possibile impostare <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> proprietà nei file csproj del generatore di origine per creare questi progetti in Live Unit Testing.

Live Unit Testing esegue la compilazione all'interno del proprio processo per motivi di prestazioni. Se questo processo di compilazione separato causa un errore, è possibile impostare <UseInProcMSBuildNode>false</UseInProcMSBuildNode> sul file .lutconfig per assicurarsi che tutta la compilazione si verifichi nel processo MSBuild.

• Un problema comune è che non tutti i file vengono copiati nella cartella di test. Potrebbe essere necessario aggiungere alcuni elementi live unit testing delle dipendenze 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, ognuno di essi deve essere aggiornato alla versione supportata.

• Assicurarsi che anche il file MSBuild props importato dal pacchetto dell'adattatore di test sia aggiornato correttamente. Controllare la versione/percorso del pacchetto NuGet dell'importazione, che in genere si trova 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 al progetto o file con estensione targets che controlla la proprietà BuildingForLiveUnitTesting ed esegue passaggi di compilazione pre/post personalizzati. È anche possibile scegliere di rimuovere determinati passaggi di compilazione( ad esempio la pubblicazione o la generazione di pacchetti) o di aggiungere passaggi di compilazione (ad esempio la copia dei prerequisiti) a una compilazione di Live Unit Testing basata su 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 esserci una destinazione che produce pacchetti NuGet durante una compilazione regolare. Probabilmente non si vuole che i pacchetti NuGet vengano generati 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 diverse differenze:

• L'esecuzione o il debug di test da Esplora test finestra di esegue normali file binari, mentre Live Unit Testing esegue file binari instrumentati. Se si desidera eseguire il debug dei file binari instrumentati, l'aggiunta di una chiamata al metodo Debugger.Launch nel metodo di test determina l'avvio del debugger ogni volta che il metodo viene eseguito (incluso quando viene eseguito da Live Unit Testing) ed è quindi possibile allegare 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 l'esecuzione dei test, ma i test eseguiti dalla finestra esplora test di creano un nuovo dominio applicazione.

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

• Esplora test esegue i 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 in STA in Live Unit Testing, decorare il metodo di test o la classe contenitore con l'attributo <STATestMethod> o <STATestClass> disponibile nel pacchetto NuGet MSTest.STAExtensions 1.0.3-beta. Per NUnit, decorare il metodo di test con l'attributo <RequiresThread(ApartmentState.STA)> e per xUnit, con l'attributo <STAFact>.

Vedere la sezione "Includere ed escludere progetti di test e metodi di test" dell'articolo Usare Live Unit Testing in Visual Studio per l'impostazione specifica dell'utente. L'inclusione o l'esclusione di test è utile quando si vuole eseguire un set specifico di test per una determinata sessione di modifica o 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 escludere metodi, proprietà, classi o strutture da instrumentare da Live Unit Testing. Inoltre, è anche possibile impostare la proprietà <ExcludeFromCodeCoverage> su true nel file di progetto per escludere l'intero progetto dall'essere 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 viene caricato nel dominio applicazione corrente e disabilitare i test in base al motivo. Ad esempio, è possibile eseguire operazioni simili alle seguenti 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. Alle destinazioni deve essere assegnato un elenco di input e output in modo che MSBuild possa eseguire i controlli up-to-date appropriati e determinare se è necessaria una nuova compilazione.

Live Unit Testing avvia una compilazione ogni volta che rileva che i file di origine sono stati modificati. 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 dal ciclo di compilazione perché i controlli di input e output indicano che tutto è up-to-date.

È possibile che nell'editor non vengano visualizzate icone se gli assembly su cui è in esecuzione Live Unit Testing non vengono instrumentati per alcun motivo. Ad esempio, Live Unit Testing non è compatibile con i progetti che impostano <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. In questo caso, il processo di compilazione deve essere aggiornato per rimuovere questa impostazione o per modificarla in true per il funzionamento di Live Unit Testing. 

È possibile eseguire diverse operazioni per raccogliere log più dettagliati:

• Passare a Tools>Opzioni>Live Unit Testing e modificare l'opzione di registrazione in dettagliato. La registrazione dettagliata determina la visualizzazione dei log più dettagliati nella finestra output.

• Impostare la variabile di ambiente utente LiveUnitTesting_BuildLog sul nome del file da usare per acquisire il log di MSBuild. I messaggi di log dettagliati di MSBuild dalle compilazioni di Live Unit Testing possono quindi essere recuperati da tale file.

• Impostare la variabile di ambiente utente LiveUnitTesting_TestPlatformLog su 1 per acquisire il log della piattaforma di test. I messaggi di log della piattaforma di test dettagliati delle esecuzioni di Live Unit Testing possono quindi essere recuperati 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 qualsiasi valore) e riavviare Visual Studio. Si noterà ora un numero elevato di accessi nella scheda output - Test in 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 il radice del repository e radice dell'area di lavoro.

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

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

Vedere anche

• live unit testing