Condividi tramite

Configurare i test unitari utilizzando un file .runsettings

  • Articolo

È 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 comune di un file .runsettings consiste nel personalizzare 'analisi del 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 è necessaria alcuna configurazione speciale, non è necessario un file .runsettings.

Creare un file di impostazioni di esecuzione e personalizzarlo

  1. Aggiungere un file di impostazioni di esecuzione alla soluzione. In Esplora soluzioni , dal menu di scelta rapida della soluzione, scegliere Aggiungi>Nuovo elementoe 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 modellie quindi scegliere il modello di elemento.

    Mancia

    Il nome del file non è importante, purché si usi l'estensione .runsettings.

  2. Aggiungere il contenuto del file esempio *.runsettingse poi personalizzarlo in base alle proprie 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 nel menu Test.

Suggerimento

È possibile creare più di un file con estensione runsettings nella soluzione e selezionare uno come file di impostazioni di test attivo in base alle esigenze.

Specificare un file di impostazioni di esecuzione 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 di impostazioni di esecuzione

Nota

Questo funzionerà solo per un file denominato .runsettings.

Per rilevare automaticamente il file delle impostazioni di esecuzione, posizionarlo nella directory principale 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>Rilevamento automatico dei file di runsettings

    Opzione di rilevamento automatico del file di runsettings in Visual Studio

  • Selezionare Test>Configurare le impostazioni di esecuzione>rilevare automaticamente i file di runsettings

    menu Rileva automaticamente il file runsettings in Visual Studio

Selezionare manualmente il file delle impostazioni di esecuzione

Nell'IDE selezionare Test>Configure Run Settings (Configura le impostazioni di esecuzione)>Seleziona il file runsettings per l'intera soluzionee quindi selezionare il file *runsettings*.

  • Questo file sovrascrive il file .runsettings alla radice della soluzione, se presente, e si applica a tutti i test eseguiti.
  • Questa selezione di file viene mantenuta solo in locale.

Selezionare il menu del file runsettings a livello di soluzione di test 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 .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>Selezionare il file di impostazioni. Passare a e selezionare il file .runsettings.

Seleziona il file delle impostazioni di test dal menu in Visual Studio 2019

Il file viene visualizzato nel menu Test ed è possibile selezionarlo o deselezionarlo. Quando selezionato, il file delle impostazioni di esecuzione viene applicato ogni volta che si seleziona Analizza la copertura del codice.

Specificare un file di impostazioni di esecuzione dalla riga di comando

Per eseguire test dalla riga di comando, usare vstest.console.exee specificare il file di impostazioni usando il parametro /Settings.

  1. Apri Prompt dei comandi per sviluppatori per Visual Studio.

  2. Immettere un comando simile al seguente:

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

    o

    vstest.console.exe --settings:test.runsettings test.dll

Per altre informazioni, vedere VSTest.Console.exe opzioni della riga di comando.

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 il file *.runsettings 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:

Nodo Predefinito Valori
MaxCpuCount 1 Il nome dell'opzione fa distinzione tra maiuscole e minuscole ed è facile da scrivere in modo errato 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) spetta al framework di test, quali MSTest, XUnit o NUnit.

Il valore predefinito è 1, ovvero un solo testhost viene eseguito contemporaneamente. Un valore speciale 0 consente il numero di testhost disponibili per 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.
RisultatiDirectory 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, ad esempio net48, net472,net6.0, net5.0, netcoreapp3.1, uap10.0 o qualsiasi nome completo valido, ad esempio.NETFramework,Version=v4.7.2 o .NETCoreApp,Version=v6.0.0. Per la compatibilità con le versioni precedenti Framework35, Framework40, Framework45, FrameworkCore10, FrameworkUap10 sono accettate, ovvero ( rispettivamentenet35, net40, net45, netcoreapp1.0 e uap10.0). 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 <TargetFramework> del progetto di 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 .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 l'esecutore di .NET Framework (in Visual Studio o vstest.console.exe nella riga di comando degli sviluppatori), 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.

Durante il rilevamento automatico, l'architettura per le DLL AnyCPU può differire in base all'esecutore. 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 falso falso, vero
PercorsiTestAdattatori Uno o più percorsi nella directory in cui si trovano i TestAdapter
TestCaseFilter Espressione di filtro nel formato proprietàoperatorevalore[|&&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 garantisce che le risorse siano ben utilizzate e che le sessioni di test siano vincolate a un tempo impostato. 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. Specificando questa opzione si evita la ricerca di testhost.exee si impone l'uso di testhost.dll.
TrattaNessunTestComeErrore falso vero o falso
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 di dati diagnostici)

L'elemento DataCollectors specifica le impostazioni degli adattatori di dati diagnostici. Gli adattatori dati di diagnostica raccolgono informazioni aggiuntive sull'ambiente e sull'applicazione sottoposta a test. Ogni adattatore ha impostazioni predefinite ed è necessario specificare le impostazioni solo se non si vogliono usare le impostazioni predefinite.

<DataCollectionRunSettings>
  <DataCollectors>
    <!-- data collectors -->
  </DataCollectors>
</DataCollectionRunSettings>

Agente di raccolta dati CodeCoverage

L'agente di raccolta dati code coverage crea un registro delle parti del codice dell'applicazione esercitate nel test. Per informazioni dettagliate sulla personalizzazione delle impostazioni di copertura del codice, consultare Personalizzare l'analisi della copertura del codice.

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

Collettore di dati VideoRecorder

L'agente di raccolta dati video acquisisce una registrazione dello schermo quando vengono eseguiti i test. Questa registrazione è utile per la risoluzione dei problemi relativi ai 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 di esempio *.runsettings .

Per personalizzare qualsiasi altro tipo di adattatori dati di diagnostica, usare un file di impostazioni di test .

Incolpa il raccoglitore di dati

Questa opzione consente di isolare un test problematico che causa un arresto anomalo dell'host di test. L'esecuzione del raccoglitore crea un file di output (Sequence.xml) in TestResults, che acquisisce l'ordine di esecuzione del test prima che si verifichi l'arresto anomalo.

È possibile eseguire il comando blame in tre diverse modalità:

  • Modalità file di sequenza: per creare un file con l'elenco dei test fino al blocco del sistema
  • Modalità dump di crash: per creare un dump quando testhost si arresta in modo anomalo
  • Modalità dump di sospensione: per creare un dump quando il test non termina prima del timeout assegnato

La configurazione XML deve essere inserita direttamente nel nodo <RunSettings>:

<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):

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à TestContext pubblica alla classe di test.

Elemento LoggerRunSettings

La sezione LoggerRunSettings 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 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>
Configurazione Predefinito Valori
ForcedLegacyMode falso Nelle versioni precedenti di Visual Studio, l'adapter MSTest è stato ottimizzato per renderlo più veloce e scalabile. Alcuni comportamenti, ad esempio l'ordine in cui vengono eseguiti i test, potrebbero non essere esattamente come nelle edizioni precedenti di Visual Studio. Impostare il valore su true per usare l'adattatore di test precedente.

Ad esempio, è possibile usare questa impostazione se è stato specificato un file app.config per uno unit test.

È consigliabile effettuare il refactoring dei test per consentire l'uso dell'adattatore più nuovo.
SettingsFile È possibile specificare un file di impostazioni di test da usare con l'adapter MSTest qui. È anche possibile specificare un file di impostazioni di test dal menu delle impostazioni.

Se si specifica questo valore, è necessario impostare anche il ForcedLegacyMode su vero.

<ForcedLegacyMode>true</ForcedLegacyMode>
DeploymentEnabled vero Se si imposta il valore su false, gli elementi di distribuzione specificati nel metodo di test non vengono copiati nella directory di distribuzione.
CaptureTraceOutput vero Acquisire messaggi di testo provenienti dalle API Console.Write*, Trace.Write*, Debug.Write* che verranno associate al test in esecuzione corrente.
AbilitaMetodiDiTestDellaClasseBaseDaAltreAsm vero 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 di ClassCleanup)
MapNotRunnableToFailed vero Un valore che indica se un risultato non eseguibile è mappato su un test fallito.
Parallelizzare Usato per impostare le impostazioni di parallelizzazione:

Lavoratori: Il numero di thread/lavoratori da usare per la parallelizzazione, che è per impostazione predefinita il numero di processori nel computer corrente.

SCOPE: L'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 falso Per segnalare gli avvisi di individuazione dei test come errori, impostare questo valore su true.
TreatClassAndAssemblyCleanupWarningsAsErrors falso Per visualizzare i fallimenti nelle operazioni di pulizia della classe come errori, impostare questo valore su true.
DeployTestSourceDependencies vero Valore che indica se i riferimenti all'origine di test devono essere distribuiti.
DeleteDeploymentDirectoryAfterTestRunIsComplete vero Per mantenere la directory di distribuzione dopo un'esecuzione di test, impostare questo valore su false.
MappaInconcludenteInFallito falso Se un test si completa con uno stato non conclusivo, viene mappato allo stato ignorato in Esplora test . Se si desidera che i test inconcludenti vengano visualizzati come non riusciti, impostare il valore su true.
ConsiderFixturesAsSpecialTests falso Per visualizzare AssemblyInitialize, AssemblyCleanup, ClassInitialize, ClassCleanup come singole voci nel registro di Visual Studio e Visual Studio Code Test Explorer e .trx, impostare questo valore su vero
RisoluzioneAssemblea falso È possibile specificare i percorsi di assembly aggiuntivi durante la ricerca e l'esecuzione di unit test. Ad esempio, 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 Percorso directory. 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 file di runsettings

Il codice XML seguente mostra il contenuto di un tipico file runsettings. Copiare questo codice e modificarlo in base alle proprie esigenze.

Ogni elemento del file è facoltativo perché ha 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 .runsettings

Le variabili di ambiente possono essere impostate nel file runsettings, che può interagire direttamente con l'host di test. È necessario specificare le variabili di ambiente nel file .runsettings per supportare progetti non intermedi 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 esempio di file delle impostazioni di esecuzione 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