Configurare unit test usando un file con estensione runsettings
È possibile usare un file con estensione runsettings per configurare la modalità di esecuzione degli unit test. Ad esempio, può essere usato per modificare la versione .NET in cui vengono eseguiti i test, la directory per i risultati del test o i dati raccolti durante un'esecuzione di test. Un uso piuttosto comune di un file con estensione runsettings è la personalizzazione dell'analisi code coverage.
I file Runsettings possono essere usati per configurare i test eseguiti dalla riga di comando, dall'IDE o in un flusso di lavoro di compilazione usando Piani di test di Azure o Azure DevOps Server (in precedenza noto come Team Foundation Server (TFS)).
I file Runsettings sono facoltativi. Se non è richiesta una configurazione particolare, non sarà necessario alcun file con estensione runsettings.
Creare un file di impostazioni di esecuzione e personalizzarlo
Aggiungere un file di impostazioni esecuzione test alla propria soluzione. In Esplora soluzioni scegliere Aggiungi>Nuovo elemento dal menu di scelta rapida della soluzione e selezionare File XML. Salvare il file con un nome, ad esempio test.runsettings.
Se non vengono visualizzati tutti i modelli di elemento, scegliere Mostra tutti i modelli e quindi scegliere il modello di elemento.
Suggerimento
Il nome del file non è rilevante, purché si usi l'estensione runsettings.
Aggiungere il contenuto dal file *.runsettings di esempio e quindi personalizzarlo in base alle esigenze, come descritto nelle sezioni seguenti.
Specificare il file *.runsettings desiderato usando uno dei metodi seguenti:
- IDE di Visual Studio
- Riga di comando
- Creare un flusso di lavoro usando Piani di test di Azure o Azure DevOps Server (in precedenza noto come Team Foundation Server (TFS)).
Eseguire gli unit test per usare le impostazioni di esecuzione personalizzate.
Se si desidera disattivare e attivare le impostazioni personalizzate nell'IDE, deselezionare o selezionare il file dal menu Test .
Suggerimento
È possibile creare più file con estensione runsettings nella soluzione e selezionarne uno come file di impostazioni test attivo in base alle esigenze.
Specificare un file di impostazioni esecuzione test nell'IDE
I metodi disponibili dipendono dalla versione di Visual Studio.
Visual Studio 2019 versione 16.4 e successive
Esistono tre modi per specificare un file di impostazioni di esecuzione in Visual Studio 2019 versione 16.4 e successive.
- Rilevamento automatico delle impostazioni di esecuzione
- Impostare manualmente le impostazioni di esecuzione
- Impostare una proprietà di compilazione
Rilevamento automatico del file delle impostazioni di esecuzione
Nota
Questo funzionerà solo per un file denominato .runsettings.
Per impostare automaticamente il file delle impostazioni di esecuzione, posizionarlo nella radice della soluzione.
Se il rilevamento automatico dei file di impostazioni di esecuzione è abilitato, le impostazioni in questo file vengono applicate in tutti i test eseguiti. È possibile attivare il rilevamento automatico dei file runsettings usando due metodi:
Selezionare Strumenti>Opzioni>Test>auto Detect runsettings Files
Selezionare Configura esecuzione test Impostazioni> Auto detect runsettings Files>
Selezionare manualmente il file delle impostazioni di esecuzione
Nell'IDE selezionare Configura esecuzione test>Impostazioni> Selezionare File runsettings a livello di soluzione e quindi selezionare il file con estensione runsettings.
- Questo file esegue l'override del file con estensione runsettings nella radice della soluzione, se presente e viene applicato in tutti i test eseguiti.
- Questa selezione di file viene mantenuta solo in locale.
Impostare una proprietà di compilazione
Aggiungere una proprietà di compilazione a un progetto tramite il file di progetto o un file Directory.Build.props. Il file delle impostazioni di esecuzione per un progetto viene specificato dalla proprietà Run Impostazioni FilePath.
- Le impostazioni di esecuzione a livello di progetto sono attualmente supportate nei progetti C#, VB, C++e F#.
- Un file specificato per un progetto esegue l'override di qualsiasi altro file di impostazioni di esecuzione specificato nella soluzione.
- Queste proprietà di MSBuild possono essere usate per specificare il percorso del file runsettings.
Esempio di specifica di un file con estensione runsettings per un progetto:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<RunSettingsFilePath>$(MSBuildProjectDirectory)\example.runsettings</RunSettingsFilePath>
</PropertyGroup>
...
</Project>
Visual Studio 2019 versione 16.3 e precedenti
Per specificare un file di impostazioni di esecuzione nell'IDE, selezionare Test>Seleziona Impostazioni File. Individuare e selezionare il file con estensione runsettings.
Il file viene visualizzato nel menu Test ed è possibile selezionarlo o deselezionarlo. Se selezionato, il file di impostazioni esecuzione test viene applicato ogni volta che si seleziona Analizza code coverage.
Specificare un file di impostazioni di esecuzione dalla riga di comando
Per eseguire i test dalla riga di comando, usare vstest.console.exe e specificare il file di impostazioni usando il parametro /Settings.
Aprire il prompt dei comandi per gli sviluppatori per Visual Studio.
Immettere un comando simile a:
vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettingsor
vstest.console.exe --settings:test.runsettings test.dll
Per altre informazioni, vedere Opzioni della riga di comando di VSTest.Console.exe.
File *.runsettings
Il file *.runsettings è un file XML che contiene elementi di configurazione diversi all'interno dell'elemento Run Impostazioni. Le sezioni che seguono illustrano in dettaglio i diversi elementi. Per un esempio completo, vedere File *.runsettings di esempio.
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- configuration elements -->
</RunSettings>
Ogni elemento di configurazione è facoltativo perché ha un valore predefinito.
Elemento RunConfiguration
<RunConfiguration>
<MaxCpuCount>1</MaxCpuCount>
<ResultsDirectory>.\TestResults</ResultsDirectory>
<TargetPlatform>x86</TargetPlatform>
<TargetFrameworkVersion>net6.0</TargetFrameworkVersion>
<TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
<TestCaseFilter>(TestCategory != Integration) & (TestCategory != UnfinishedFeature)</TestCaseFilter>
<TestSessionTimeout>10000</TestSessionTimeout>
<TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>
L'elemento RunConfiguration può includere gli elementi seguenti:
| Nodo | Default | Valori |
|---|---|---|
| MaxCpuCount | 1 | Il nome dell'opzione fa distinzione tra maiuscole e minuscole ed è facile da digitare come MaxCPUCount. Questa impostazione controlla il livello di parallelismo a livello di processo. Usare 0 per abilitare il parallelismo massimo a livello di processo. Questa impostazione determina il numero massimo di DLL di test o altri contenitori di test che possono essere eseguiti in parallelo. Ogni DLL viene eseguita nel proprio processo testhost ed è isolata a livello di processo dai test in altre DLL di test. Questa impostazione non forza l'esecuzione dei test in ogni DLL di test in parallelo. Il controllo dell'esecuzione parallela all'interno di una DLL (a livello di thread) è fino al framework di test, ad esempio MSTest, XUnit o NUnit. Il valore predefinito è 1, ovvero un solo testhost viene eseguito contemporaneamente. Un valore 0 speciale consente il numero di testhost che si dispone di processori logici (ad esempio, 6, per un computer con 6 core fisici senza multithreading o 12, per un computer con sei core fisici con multithreading).Il numero di DLL distinte nell'esecuzione determina il numero effettivo di testhost avviati. |
| ResultsDirectory | Directory in cui vengono inseriti i risultati del test. Il percorso è relativo alla directory che contiene il file con estensione runsettings. | |
| TargetFrameworkVersion | net40 o netcoreapp1.0 | Omettere l'intero tag per rilevare automaticamente. Questa impostazione definisce la versione del framework o la famiglia di framework da usare per eseguire i test. I valori accettati sono qualsiasi moniker del framework, net48ad esempio , net472,net6.0net5.0 , netcoreapp3.1uap10.0 o qualsiasi nome di framework completo valido, ad esempio.NETFramework,Version=v4.7.2 o .NETCoreApp,Version=v6.0.0. Per la compatibilità Framework35con le versioni precedenti, , Framework40Framework45, FrameworkCore10, FrameworkUap10 vengono accettati, ovvero (net35, net40net45, netcoreapp1.0 e uap10.0 rispettivamente). Tutti i valori non fanno distinzione tra maiuscole e minuscole.Il valore specificato viene usato per determinare il provider di runtime di test da usare. Ogni provider di runtime di test deve rispettare la famiglia di framework da usare, ma potrebbe non rispettare la versione esatta del framework: Per .NET Framework 4.5.1 - 4.8 viene usato un testhost compilato con la versione esatta specificata. Per i valori esterni a tale intervallo, viene usato testhost di .NET Framework 4.5.1. Per .NET, il progetto di <TargetFramework> test (o più precisamente runtimeconfig.json) determina la versione effettiva.Per la piattaforma UWP, l'applicazione di progetto di test è un testhost da solo e determina la versione effettiva della piattaforma UWP usata. Omettere l'elemento TargetFrameworkVersion dal file con estensione runsettings per determinare automaticamente la versione del framework dai file binari compilati.Quando si rileva automaticamente, tutti i framework di destinazione vengono unificati in un singolo framework comune. Quando viene trovata una versione diversa dalla stessa famiglia di framework di destinazione, viene scelta la versione più recente, ad esempio net452, net472, net48 = net48. Per lo strumento di esecuzione di .NET Framework (in Visual Studio o vstest.console.exe nella riga di comando Developer), il framework di destinazione comune è net40. Per .NET runner (dotnet test + DLL), il framework di destinazione comune è impostato su netcoreapp1.0. |
| TargetPlatform | x86 | Omettere l'intero tag per rilevare automaticamente. Questa impostazione definisce l'architettura da usare per eseguire i test. I valori possibili sono x86, x64, ARM, ARM64, S390x.Quando si rileva automaticamente, l'architettura per le DLL AnyCPU può differire in base allo strumento di esecuzione. Per lo strumento di esecuzione di .NET Framework (in Visual Studio o vstest.console.exe nella riga di comando developer), il valore predefinito è x86. Per .NET runner (test dotnet), il valore predefinito è l'architettura del processo corrente. |
| TreatTestAdapterErrorsAsWarnings | false | false, true |
| TestAdaptersPaths | Uno o più percorsi della directory in cui si trovano i TestAdapter | |
| TestCaseFilter | Espressione di filtro nel valore> dell'operatore><< di proprietà><format[|&<Espressione>]. L'operatore booleano & deve essere rappresentato dall'entità HTML &. Le espressioni possono essere racchiuse tra parentesi. Per una sintassi dettagliata sulla struttura delle espressioni, vedere vstest/docs/filter.md. | |
| TestSessionTimeout | Consente agli utenti di terminare una sessione di test allo scadere di un timeout specificato. L'impostazione di un timeout assicura un consumo ottimale delle risorse e consente di vincolare le sessioni di test a un periodo di tempo stabilito. L'impostazione è disponibile in Visual Studio 2017 versione 15.5 e versioni successive. | |
| DotnetHostPath | Specificare un percorso personalizzato per l'host dotnet usato per eseguire testhost. È utile quando si compila una propria dotnet, ad esempio quando si compila il repository dotnet/runtime. Se si specifica questa opzione, viene ignorata la ricerca di testhost.exe e viene forzata l'uso di testhost.dll. | |
| TreatNoTestsAsError | false | true o false Specificare un valore booleano che definisce il codice di uscita quando non vengono individuati test. Se il valore è true e non vengono individuati test, viene restituito un codice di uscita diverso da zero. In caso contrario, viene restituito zero. |
Elemento DataCollectors (adattatori dati di diagnostica)
L'elemento DataCollectors specifica le impostazioni degli adattatori dati di diagnostica. Gli adattatori dati di diagnostica raccolgono informazioni aggiuntive sull'ambiente e l'applicazione sottoposta a test. Le impostazioni di ogni adattatore sono predefinite. È quindi necessario specificarle solo se non si vogliono usare quelle predefinite.
<DataCollectionRunSettings>
<DataCollectors>
<!-- data collectors -->
</DataCollectors>
</DataCollectionRunSettings>
Agente di raccolta dati CodeCoverage
L'agente di raccolta dati di code coverage crea un log in cui le parti del codice dell'applicazione sono state eseguite nel test. Per informazioni dettagliate sulla personalizzazione delle impostazioni per il code coverage, vedere Personalizzare l'analisi del code coverage.
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<ModulePaths>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
Agente di raccolta dati VideoRecorder
L'agente di raccolta dati video acquisisce la registrazione di una schermata quando si eseguono i test. La registrazione è utile per la risoluzione dei test dell'interfaccia utente. L'agente di raccolta dati video è disponibile in Visual Studio 2017 versione 15.5 e versioni successive. Per un esempio di configurazione di questo agente di raccolta dati, vedere il file example *.runsettings.
Per personalizzare qualsiasi altro tipo di adattatore dati di diagnostica, usare un file di impostazioni di test.
Agente di raccolta dati colpa
Questa opzione consente di isolare un test problematico che causa un arresto anomalo dell'host di test. L'esecuzione dell'agente di raccolta crea un file di output (Sequence.xml) in TestResults, che acquisisce l'ordine di esecuzione del test prima dell'arresto anomalo.
È possibile eseguire la colpa in tre diverse modalità:
- Modalità file di sequenza: per creare un file con l'elenco dei test fino al blocco
- Modalità dump di arresto anomalo del sistema: per creare un dump quando testhost si arresta in modo anomalo
- Modalità dump di blocco: per creare un dump quando il test non termina prima del timeout specificato
La configurazione XML deve essere inserita direttamente nel <RunSettings> nodo:
<RunSettings>
<RunConfiguration>
</RunConfiguration>
<LoggerRunSettings>
<Loggers>
<Logger friendlyName="blame" enabled="True" />
</Loggers>
</LoggerRunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<!-- Enables blame -->
<DataCollector friendlyName="blame" enabled="True">
<Configuration>
<!-- Enables crash dump, with dump type "Full" or "Mini".
Requires ProcDump in PATH for .NET Framework. -->
<CollectDump DumpType="Full" />
<!-- Enables hang dump or testhost and its child processes
when a test hangs for more than 10 minutes.
Dump type "Full", "Mini" or "None" (just kill the processes). -->
<CollectDumpOnTestSessionHang TestTimeout="10min" HangDumpType="Full" />
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
TestRunParameters
<TestRunParameters>
<Parameter name="webAppUrl" value="http://localhost" />
<Parameter name="docsUrl" value="https://learn.microsoft.com" />
</TestRunParameters>
I parametri di esecuzione dei test consentono di definire variabili e valori disponibili per i test in fase di esecuzione. Accedere ai parametri usando la proprietà MSTest TestContext.Properties (o NUnit TestContext):
private string _appUrl;
public TestContext TestContext { get; set; }
[TestMethod] // [Test] for NUnit
public void HomePageTest()
{
string _appUrl = TestContext.Properties["webAppUrl"];
}
Per usare i parametri di esecuzione dei test, aggiungere una proprietà pubblica TestContext alla classe di test.
Elemento LoggerRun Impostazioni
La LoggerRunSettings sezione definisce uno o più logger da usare per l'esecuzione del test. I logger più comuni sono console, Visual Studio Test Results File (trx) e html.
<LoggerRunSettings>
<Loggers>
<Logger friendlyName="console" enabled="True">
<Configuration>
<Verbosity>quiet</Verbosity>
</Configuration>
</Logger>
<Logger friendlyName="trx" enabled="True">
<Configuration>
<LogFileName>foo.trx</LogFileName>
</Configuration>
</Logger>
<Logger friendlyName="html" enabled="True">
<Configuration>
<LogFileName>foo.html</LogFileName>
</Configuration>
</Logger>
</Loggers>
</LoggerRunSettings>
Elemento MSTest
Queste impostazioni sono specifiche dell'adattatore di test che esegue i metodi di test con l'attributo TestMethodAttribute .
<MSTest>
<MapInconclusiveToFailed>True</MapInconclusiveToFailed>
<CaptureTraceOutput>false</CaptureTraceOutput>
<DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
<DeploymentEnabled>False</DeploymentEnabled>
<AssemblyResolution>
<Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
</AssemblyResolution>
</MSTest>
| Impostazione | Default | Valori |
|---|---|---|
| ForcedLegacyMode | false | Nelle versioni precedenti di Visual Studio, l'adapter MSTest è stato ottimizzato per renderlo più veloce e scalabile. Un comportamento, ad esempio l'ordine in cui vengono eseguiti i test, potrebbe non essere esattamente come quello nelle versioni precedenti di Visual Studio. Impostare il valore su true per usare l'adattatore di test precedente. Lo si può usare, ad esempio, nel caso in cui sia presente un file app.config specificato per uno unit test. È consigliabile provare a effettuare il refactoring dei test per consentire l'uso dell'adattatore più recente. |
| SettingsFile | È possibile specificare un file di impostazioni test da usare con l'adattatore MSTest. È anche possibile specificare un file di impostazioni test dal menu delle impostazioni. Se si specifica questo valore, è necessario impostare anche ForcedLegacyMode su true. <ForcedLegacyMode>true</ForcedLegacyMode> |
|
| DeploymentEnabled | true | Se si imposta il valore su false, gli elementi della distribuzione specificati nel metodo di test non vengono copiati nella directory di distribuzione. |
| CaptureTraceOutput | true | Acquisire messaggi di testo provenienti da Console.Write*, Trace.Write*, Debug.Write* API che verrà associata al test in esecuzione corrente. |
| EnableBaseClassTestMethodsFromOtherAssemblies | true | Valore che indica se abilitare l'individuazione dei metodi di test da classi di base in un assembly diverso dalla classe di test che eredita. |
| ClassCleanupLifecycle | EndOfClass | Se si desidera che la pulizia della classe venga eseguita alla fine dell'assembly, impostarla su EndOfAssembly. (Non più supportato a partire da MSTest v4 come EndOfClass è l'impostazione predefinita e solo Comportamento classCleanup ) |
| MapNotRunnableToFailed | true | Valore che indica se viene eseguito il mapping di un risultato non eseguibile a un test non superato. |
| Parallelizzare | Usato per impostare le impostazioni di parallelizzazione: Ruoli di lavoro: numero di thread/ruoli di lavoro da usare per la parallelizzazione, ovvero per impostazione predefinita il numero di processori nel computer corrente. SCOPE: ambito della parallelizzazione. È possibile impostarlo su MethodLevel. Per impostazione predefinita, è ClassLevel. <Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize> |
|
| TestTimeout | 0 | Ottiene il timeout del test case globale specificato. |
| TreatDiscoveryWarningsAsErrors | false | Per segnalare gli avvisi di individuazione dei test come errori, impostare questo valore su true. |
| TreatClassAndAssemblyCleanupWarningsAsErrors | false | Per visualizzare gli errori nelle operazioni di pulizia della classe come errori, impostare questo valore su true. |
| DeployTestSourceDependencies | true | Valore che indica se i riferimenti all'origine di test devono essere distribuiti. |
| DeleteDeploymentDirectoryAfterTestRunIsComplete | true | Per mantenere la directory di distribuzione dopo un'esecuzione di test, impostare questo valore su false. |
| MapInconclusiveToFailed | false | Se un test viene completato con uno stato inconcludente, viene mappato allo stato ignorato in Esplora test. Se si vuole che i test senza risultati vengano visualizzati come non superati, impostare il valore su true. |
| AssemblyResolution | false | È possibile specificare i percorsi di assembly aggiuntivi durante la ricerca e l'esecuzione di unit test. Ad esempio, è possibile usare questi percorsi per gli assembly di dipendenza che non si trovano nella stessa directory dell'assembly di test. Per specificare un percorso, usare un elemento Directory Path. I percorsi possono includere variabili di ambiente.<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>Si noti che questa funzionalità viene applicata solo quando si usa la destinazione .NET Framework. |
Esempio di file con estensione runsettings
Il codice XML seguente rappresenta il contenuto di un tipico file con estensione runsettings. Copiare questo codice e modificarlo in base alle esigenze.
Ogni elemento del file è facoltativo perché usa un valore predefinito.
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- Configurations that affect the Test Framework -->
<RunConfiguration>
<!-- Use 0 for maximum process-level parallelization. This does not force parallelization within the test DLL (on the thread-level). You can also change it from the Test menu; choose "Run tests in parallel". Unchecked = 1 (only 1), checked = 0 (max). -->
<MaxCpuCount>1</MaxCpuCount>
<!-- Path relative to directory that contains .runsettings file-->
<ResultsDirectory>.\TestResults</ResultsDirectory>
<!-- Omit the whole tag for auto-detection. -->
<!-- [x86] or x64, ARM, ARM64, s390x -->
<!-- You can also change it from the Test menu; choose "Processor Architecture for AnyCPU Projects" -->
<TargetPlatform>x86</TargetPlatform>
<!-- Any TargetFramework moniker or omit the whole tag for auto-detection. -->
<!-- net48, [net40], net6.0, net5.0, netcoreapp3.1, uap10.0 etc. -->
<TargetFrameworkVersion>net40</TargetFrameworkVersion>
<!-- Path to Test Adapters -->
<TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
<!-- TestCaseFilter expression -->
<TestCaseFilter>(TestCategory != Integration) & (TestCategory != UnfinishedFeature)</TestCaseFilter>
<!-- TestSessionTimeout was introduced in Visual Studio 2017 version 15.5 -->
<!-- Specify timeout in milliseconds. A valid value should be greater than 0 -->
<TestSessionTimeout>10000</TestSessionTimeout>
<!-- true or false -->
<!-- Value that specifies the exit code when no tests are discovered -->
<TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>
<!-- Configurations for data collectors -->
<DataCollectionRunSettings>
<DataCollectors>
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Configuration>
<CodeCoverage>
<ModulePaths>
<Exclude>
<ModulePath>.*CPPUnitTestFramework.*</ModulePath>
</Exclude>
</ModulePaths>
<!-- We recommend you do not change the following values: -->
<UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
<AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
<CollectFromChildProcesses>True</CollectFromChildProcesses>
<CollectAspDotNet>False</CollectAspDotNet>
</CodeCoverage>
</Configuration>
</DataCollector>
<DataCollector uri="datacollector://microsoft/VideoRecorder/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder.VideoRecorderDataCollector, Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Screen and Voice Recorder">
<!--Video data collector was introduced in Visual Studio 2017 version 15.5 -->
<Configuration>
<!-- Set "sendRecordedMediaForPassedTestCase" to "false" to add video attachments to failed tests only -->
<MediaRecorder sendRecordedMediaForPassedTestCase="true" xmlns="">
<ScreenCaptureVideo bitRate="512" frameRate="2" quality="20" />
</MediaRecorder>
</Configuration>
</DataCollector>
<!-- Configuration for blame data collector -->
<DataCollector friendlyName="blame" enabled="True">
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
<!-- Parameters used by tests at run time -->
<TestRunParameters>
<Parameter name="webAppUrl" value="http://localhost" />
<Parameter name="webAppUserName" value="Admin" />
<Parameter name="webAppPassword" value="Password" />
</TestRunParameters>
<!-- Configuration for loggers -->
<LoggerRunSettings>
<Loggers>
<Logger friendlyName="console" enabled="True">
<Configuration>
<Verbosity>quiet</Verbosity>
</Configuration>
</Logger>
<Logger friendlyName="trx" enabled="True">
<Configuration>
<LogFileName>foo.trx</LogFileName>
</Configuration>
</Logger>
<Logger friendlyName="html" enabled="True">
<Configuration>
<LogFileName>foo.html</LogFileName>
</Configuration>
</Logger>
<Logger friendlyName="blame" enabled="True" />
</Loggers>
</LoggerRunSettings>
<!-- Adapter Specific sections -->
<!-- MSTest adapter -->
<MSTest>
<MapInconclusiveToFailed>True</MapInconclusiveToFailed>
<CaptureTraceOutput>false</CaptureTraceOutput>
<DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
<DeploymentEnabled>False</DeploymentEnabled>
<AssemblyResolution>
<Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
</AssemblyResolution>
</MSTest>
</RunSettings>
Specificare le variabili di ambiente nel file con estensione runsettings
Le variabili di ambiente possono essere impostate nel file con estensione runsettings , che può interagire direttamente con l'host di test. Specificare le variabili di ambiente nel file con estensione runsettings è necessario per supportare progetti nontriviali che richiedono l'impostazione di variabili di ambiente come DOTNET_ROOT. Queste variabili vengono impostate durante la generazione del processo host di test e sono disponibili nell'host.
Esempio
Il codice seguente è un file con estensione runsettings di esempio che passa le variabili di ambiente:
<?xml version="1.0" encoding="utf-8"?>
<!-- File name extension must be .runsettings -->
<RunSettings>
<RunConfiguration>
<EnvironmentVariables>
<!-- List of environment variables we want to set-->
<DOTNET_ROOT>C:\ProgramFiles\dotnet</DOTNET_ROOT>
<SDK_PATH>C:\Codebase\Sdk</SDK_PATH>
</EnvironmentVariables>
</RunConfiguration>
</RunSettings>
Il nodo RunConfiguration deve contenere un nodo EnvironmentVariables . È possibile specificare una variabile di ambiente come nome di elemento e il relativo valore.
Nota
Poiché queste variabili di ambiente devono essere sempre impostate all'avvio dell'host di test, i test devono essere sempre eseguiti in un processo separato. Per questo motivo, il flag /InIsolation verrà impostato quando sono presenti variabili di ambiente in modo che l'host di test venga sempre richiamato.
Contenuto correlato
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per