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

  1. 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.

  2. Aggiungere il contenuto dal file *.runsettings di esempio e quindi personalizzarlo in base alle esigenze, come descritto nelle sezioni seguenti.

  3. Specificare il file *.runsettings desiderato usando uno dei metodi seguenti:

  4. 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 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

    Opzione Di rilevamento automatico del file runsettings in Visual Studio

  • Selezionare Configura configurazione esecuzione>Rileva automaticamente i file di runsettings>

    Rilevamento automatico del menu file runsettings in Visual Studio

Selezionare manualmente il file delle impostazioni di esecuzione

Nell'IDE selezionare Configura impostazioni>esecuzione Test>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.

Selezionare il menu test del file runsettings a livello di soluzione in Visual Studio

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à RunSettingsFilePath.

  • 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 Select Settings File (Test>Select Settings File). Individuare e selezionare il file con estensione runsettings.

Selezionare il menu di file di impostazioni test in Visual Studio 2019

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.

  1. Aprire il prompt dei comandi per gli sviluppatori per Visual Studio.

  2. Immettere un comando simile a:

    vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettings
    

    or

    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 RunSettings . 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) &amp; (TestCategory != UnfinishedFeature)</TestCaseFilter>
    <TestSessionTimeout>10000</TestSessionTimeout>
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>

L'elemento RunConfiguration può includere gli elementi seguenti:

Node Predefiniti 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 quando supera un determinato timeout, specificato in millisecondi. 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://video2.skills-academy.com" />
</TestRunParameters>

I parametri di esecuzione dei test consente di definire le variabili e i 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 del test, aggiungere una proprietà TestContext pubblica alla classe di test.

Elemento LoggerRunSettings

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>
    <ConsiderFixturesAsSpecialTests>False</ConsiderFixturesAsSpecialTests>
    <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 essere più veloce e più 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, poiché EndOfClass è il comportamento predefinito e unico di ClassCleanup)
MapNotRunnableToFailed true Valore che indica se viene eseguito il mapping di un risultato non eseguibile a un test non superato.
Parallelizzazione Si usa per impostare le impostazioni relative alla parallelizzazione:

Ruolo di lavoro: numero di thread/ruoli di lavoro da usare per la parallelizzazione, che è per impostazione predefinita il numero di processori nel computer corrente.

AMBITO: 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 del 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 senza risultati, ne viene eseguito il mapping allo stato Ignorato in Esplora test. Se si vuole che i test senza risultati vengano visualizzati come non superati, impostare il valore su true.
ConsiderFixturesAsSpecialTests false Per visualizzare , , , come singole voci in Visual Studio e Visual Studio Code Test Explorer e .trx log, impostare questo valore su true ClassCleanup ClassInitializeAssemblyCleanupAssemblyInitialize
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) &amp; (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.