Eenheidstests configureren met behulp van een .runsettings-bestand

Artikel
01/27/2025

Een .runsettings--bestand kan worden gebruikt om te configureren hoe eenheidstests worden uitgevoerd. Het kan bijvoorbeeld worden gebruikt om de .NET-versie te wijzigen waarop de tests worden uitgevoerd, de map voor de testresultaten of de gegevens die tijdens een testuitvoering worden verzameld. Een veelvoorkomend gebruik van een .runsettings-bestand is het aanpassen van codedekkingsanalyse.

Runsettings-bestanden kunnen worden gebruikt om tests te configureren die worden uitgevoerd vanaf de opdrachtregel, vanuit de IDE of in een buildwerkstroom met behulp van Azure Test Plans of Azure DevOps Server (voorheen Bekend als Team Foundation Server (TFS)).

Runsettings-bestanden zijn optioneel. Als u geen speciale configuratie nodig hebt, hebt u geen .runsettings--bestand nodig.

Een bestand met uitvoeringsinstellingen maken en aanpassen

Voeg een bestand met uitvoeringsinstellingen toe aan uw oplossing. Kies in Solution Explorerin het snelmenu van uw oplossing Toevoegen>nieuw itemen selecteer XML-bestand. Sla het bestand op met een naam zoals test.runsettings.

Als u niet alle itemsjablonen ziet, kiest u Alle sjablonen weergevenen kiest u vervolgens de itemsjabloon.

Tip

De bestandsnaam maakt niet uit, zolang u de extensie .runsettingsgebruikt.
Voeg de inhoud uit voorbeeldbestand *.runsettings-bestand toeen pas deze vervolgens aan uw behoeften aan zoals beschreven in de volgende secties.
Geef het *.runsettings-bestand op dat u wilt gebruiken met een van de volgende methoden:
- Visual Studio IDE
- opdrachtregel
- Werkstroom bouwen met behulp van Azure Test Plans of Azure DevOps Server (voorheen Team Foundation Server (TFS) genoemd).
Voer de eenheidstests uit om de aangepaste uitvoeringsinstellingen te gebruiken.

Als u de aangepaste instellingen wilt uitschakelen en inschakelen in de IDE, schakelt u het bestand uit of selecteert u het bestand in het menu Test.

Tip

U kunt meer dan één .runsettings--bestand maken in uw oplossing en een bestand selecteren als het actieve testinstellingenbestand indien nodig.

Een bestand met uitvoeringsinstellingen opgeven in de IDE

De beschikbare methoden zijn afhankelijk van uw versie van Visual Studio.

Visual Studio 2019 versie 16.4 en hoger

Er zijn drie manieren om een bestand met uitvoeringsinstellingen op te geven in Visual Studio 2019 versie 16.4 en hoger.

de uitvoeringsinstellingen automatisch detecteren
de uitvoeringsinstellingen handmatig instellen
Stel een build-eigenschap in

Het bestand met uitvoeringsinstellingen automatisch detecteren

Notitie

Dit werkt alleen voor een bestand met de naam .runsettings.

Als u het bestand met uitvoeringsinstellingen automatisch wilt detecteren, plaatst u het in de hoofdmap van uw oplossing.

Als automatische detectie van uitvoeringsinstellingenbestanden is ingeschakeld, worden de instellingen in dit bestand toegepast op alle tests die worden uitgevoerd. U kunt automatische detectie van runsettings-bestanden inschakelen met behulp van twee methoden:

Selecteer Tools>Options>Test>Auto Detect runsettings Files
Selecteer Test>Uitvoeringsinstellingen configureren>Automatisch detecteren van runsettings-bestanden

Selecteer handmatig het bestand met uitvoeringsinstellingen

Selecteer in de IDE Test>Uitvoeringsinstellingen configureren>Solution Wide runsettingsbestand selecterenen selecteer vervolgens het .runsettings-bestand.

Dit bestand overschrijft de .runsettings--bestanden in de hoofdmap van de oplossing, indien aanwezig, en geldt voor alle uitgevoerde tests.
Deze bestandsselectie blijft alleen lokaal behouden.

Selecteer in Visual Studio het menu voor het oplossing-brede runsettingsbestand

Een build-eigenschap instellen

Voeg een build-eigenschap toe aan een project via het projectbestand of een Directory.Build.props-bestand. Het bestand met uitvoeringsinstellingen voor een project wordt opgegeven door de eigenschap RunSettingsFilePath.

Uitvoeringsinstellingen op projectniveau worden momenteel ondersteund in C#-, VB-, C++- en F#-projecten.
Een bestand dat is opgegeven voor een project overschrijft elk ander bestand met uitvoeringsinstellingen dat is opgegeven in de oplossing.
Deze MSBuild-eigenschappen kunnen worden gebruikt om het pad naar het runettings-bestand op te geven.

Voorbeeld van het opgeven van een .runsettings--bestand voor een project:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <RunSettingsFilePath>$(MSBuildProjectDirectory)\example.runsettings</RunSettingsFilePath>
  </PropertyGroup>
  ...
</Project>

Visual Studio 2019 versie 16.3 en eerder

Als u een bestand met uitvoeringsinstellingen in de IDE wilt opgeven, selecteert u Test>Instellingenbestand selecteren. Blader naar en selecteer het bestand .runsettings.

Selecteer het menu Bestand met testinstellingen in Visual Studio 2019

Het bestand wordt weergegeven in het menu Test en u kunt het selecteren of deselecteren. Terwijl dit is geselecteerd, is het bestand met uitvoeringsinstellingen van toepassing wanneer u Codedekking analyserenselecteert.

Een bestand met uitvoeringsinstellingen opgeven vanaf de opdrachtregel

Als u tests vanaf de opdrachtregel wilt uitvoeren, gebruikt u vstest.console.exeen geeft u het instellingenbestand op met behulp van de parameter /Settings.

Openen Developer Command Prompt voor Visual Studio.

Voer een opdracht in die vergelijkbaar is met:

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

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

Zie VSTest.Console.exe opdrachtregeloptiesvoor meer informatie.

Het bestand *.runsettings

Het bestand *.runsettings is een XML-bestand dat verschillende configuratie-elementen bevat in de RunSettings element. De secties die volgen, beschrijven de verschillende elementen. Zie voorbeeld *.runsettings-bestandvoor een volledig voorbeeld.

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- configuration elements -->
</RunSettings>

Elk van de configuratie-elementen is optioneel omdat deze een standaardwaarde heeft.

RunConfiguration-element

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

Het element RunConfiguration kan de volgende elementen bevatten:

Knoop	Verstek	Waarden
MaxCpuCount	1	De naam van de optie is hoofdlettergevoelig en kan gemakkelijk verkeerd gespeld worden als MaxCPUCount. Deze instelling bepaalt het niveau van parallelle uitvoering op procesniveau. Gebruik 0 om parallelle uitvoering op procesniveau in te schakelen. Deze instelling bepaalt het maximum aantal test-DLL's of andere testcontainers die parallel kunnen worden uitgevoerd. Elk DLL-bestand wordt uitgevoerd in een eigen testhostproces en wordt geïsoleerd op procesniveau van de tests in andere test-DLL's. Met deze instelling worden tests in elke test-DLL niet geforceerd parallel uitgevoerd. Het beheren van de parallelle uitvoering binnen een DLL (op threadniveau) ligt bij het testframework, zoals MSTest, XUnit of NUnit. De standaardwaarde is `1`, wat betekent dat slechts één testhost tegelijkertijd wordt uitgevoerd. Een speciale waarde `0` zoveel testhosts toestaat als u logische processors hebt (bijvoorbeeld 6, voor een computer met 6 fysieke kernen zonder multithreading, of 12, voor een computer met zes fysieke kernen met meerdere threading). Het aantal afzonderlijke DLL's in de uitvoering bepaalt het werkelijke aantal testhosts dat is gestart.
ResultsDirectory		De map waarin testresultaten worden geplaatst. Het pad is relatief ten opzichte van de map die het .runsettings-bestand bevat.
TargetFrameworkVersion	net40 of netcoreapp1.0	deze hele tag weglaten om automatische detectie mogelijk te maken. Met deze instelling definieert u de frameworkversie of frameworkfamilie die moet worden gebruikt om tests uit te voeren. Geaccepteerde waarden zijn framework moniker zoals `net48`, `net472`,`net6.0`, `net5.0`, `netcoreapp3.1`, `uap10.0` of een geldige volledige frameworknaam zoals`.NETFramework,Version=v4.7.2` of `.NETCoreApp,Version=v6.0.0`. Voor achterwaartse compatibiliteit `Framework35`, `Framework40`, `Framework45`, `FrameworkCore10`, worden `FrameworkUap10` geaccepteerd, wat betekent (`net35`, `net40`, `net45`, respectievelijk `netcoreapp1.0` en `uap10.0`). Alle waarden zijn niet hoofdlettergevoelig. De opgegeven waarde wordt gebruikt om te bepalen welke testruntimeprovider moet worden gebruikt. Elke testruntimeprovider moet de frameworkfamilie respecteren die moet worden gebruikt, maar mogelijk niet de exacte frameworkversie: Voor .NET Framework 4.5.1 - 4.8 wordt een testhost gebruikt die is gebouwd met de opgegeven exacte versie. Voor waarden buiten dat bereik wordt .NET Framework 4.5.1-testhost gebruikt. Voor .NET bepaalt de `<TargetFramework>` van het testproject (of nauwkeuriger `runtimeconfig.json`) de werkelijke versie. Voor UWP is de testprojecttoepassing zelf een testhost en bepaalt de daadwerkelijke versie van UWP die wordt gebruikt. Laat het `TargetFrameworkVersion`-element weg uit het bestand .runsettings om automatisch de frameworkversie van de ingebouwde binaire bestanden te bepalen. Bij autodetectie worden alle doelframeworks verenigd in een gemeenschappelijk framework. Wanneer een andere versie dan dezelfde doelframeworkfamilie wordt gevonden, wordt de nieuwere versie gekozen (bijvoorbeeld net452, net472, net48 = net48). Voor de .NET Framework-runner (in Visual Studio of vstest.console.exe in de ontwikkelaar-opdrachtregel) is het gebruikelijke doelframework net40. Voor .NET-runner (dotnet-test + DLL's) is het algemene doelframework ingesteld op netcoreapp1.0.
TargetPlatform-	x86	deze hele tag weglaten om automatisch te detecteren. Deze instelling definieert de architectuur die moet worden gebruikt voor het uitvoeren van tests. Mogelijke waarden zijn `x86`, `x64`, `ARM`, `ARM64`, `S390x`. Bij automatisch detecteren kan de architectuur voor AnyCPU DLL's verschillen afhankelijk van de runner. Voor .NET Framework runner (in Visual Studio of vstest.console.exe in de opdrachtregel voor ontwikkelaars) is de standaardwaarde x86. Voor .NET runner (dotnet-test) is de standaardwaarde de huidige procesarchitectuur.
TreatTestAdapterErrorsAsWarnings	vals	onwaar, waar
TestAdaptersPaths		Een of meer paden naar de map waar de TestAdapters zich bevinden
TestCaseFilter		Een filterexpressie in het formaat <eigenschap><operator><waarde>[\|&en<Expressie>]. De booleaanse operator & moet worden vertegenwoordigd door de HTML-entiteit &. Expressies kunnen tussen haakjes worden weergegeven. Zie vstest/docs/filter.mdvoor gedetailleerde syntaxis voor expressiestructuur.
TestSessionTimeout		Hiermee kunnen gebruikers een testsessie beëindigen wanneer deze een bepaalde time-out overschrijdt, opgegeven in milliseconden. Het instellen van een time-out zorgt ervoor dat resources goed worden gebruikt en testsessies worden beperkt tot een ingestelde tijd. De instelling is beschikbaar in Visual Studio 2017 versie 15.5 en hoger.
DotnetHostPath		Geef een aangepast pad op naar de dotnet-host die wordt gebruikt om de testhost uit te voeren. Het is handig wanneer u uw eigen dotnet bouwt, bijvoorbeeld bij het bouwen van de dotnet/runtime-opslagplaats. Als u deze optie opgeeft, wordt het zoeken naar testhost.exeovergeslagen en wordt testhost.dllverplicht gebruikt.
TreatNoTestsAsError-	onwaar	waar of onwaar Geef een Booleaanse waarde op, waarmee de afsluitcode wordt gedefinieerd wanneer er geen tests worden gedetecteerd. Als de waarde is `true` en er geen tests worden gedetecteerd, wordt er een niet-nul-afsluitcode geretourneerd. Anders wordt nul geretourneerd.

Het element 'DataCollectors' (diagnostische gegevensadapters)

De DataCollectors element geeft instellingen van diagnostische gegevensadapters. Diagnostische gegevensadapters verzamelen aanvullende informatie over de omgeving en de toepassing die wordt getest. Elke adapter heeft standaardinstellingen en u hoeft alleen instellingen op te geven als u de standaardinstellingen niet wilt gebruiken.

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

CodeCoverage-gegevensverzamelaar

De gegevensverzamelaar voor codedekking maakt een logboek van welke onderdelen van de toepassingscode in de test zijn uitgevoerd. Zie Analyse van codedekking aanpassenvoor gedetailleerde informatie over het aanpassen van de instellingen voor codedekking.

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

VideoRecorder-gegevensverzamelaar

De videogegevensverzamelaar legt een schermopname vast wanneer tests worden uitgevoerd. Deze opname is handig voor het oplossen van problemen met UI-tests. De videogegevensverzamelaar is beschikbaar in Visual Studio 2017 versie 15.5 en hoger. Zie het voorbeeldbestand *.runsettings-bestandvoor een voorbeeld van het configureren van deze gegevensverzamelaar.

Als u elk ander type diagnostische gegevensadapters wilt aanpassen, gebruikt u een bestand met testinstellingen.

Gegevensverzamelaar de schuld geven

Met deze optie kunt u een problematische test isoleren die een crash van de testhost veroorzaakt. Als u de collector uitvoert, wordt een uitvoerbestand (Sequence.xml) gemaakt in TestResults, waarmee de volgorde van uitvoering van de test vóór de crash wordt vastgelegd.

U kunt 'blame' in drie verschillende modi uitvoeren:

Sequentiebestandsmodus: om een bestand te maken met de lijst met tests tot aan de vastloper
Crashdumpmodus: een dump maken wanneer testhost vastloopt
Dumpmodus vastlopen: om een dump te maken wanneer de test niet is voltooid vóór de opgegeven time-out

De XML-configuratie moet rechtstreeks in <RunSettings> knooppunt worden geplaatst:

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

Testuitvoeringsparameters bieden een manier om variabelen en waarden te definiëren die tijdens runtime beschikbaar zijn voor de tests. Open de parameters met behulp van de eigenschap MSTest TestContext.Properties (of de NUnit TestContext):

public TestContext TestContext { get; set; }

[TestMethod] // [Test] for NUnit
public void HomePageTest()
{
    string appUrl = TestContext.Properties["webAppUrl"];
}

Als u testuitvoeringsparameters wilt gebruiken, voegt u een openbare TestContext eigenschap toe aan uw testklasse.

Het element LoggerRunSettings

De sectie LoggerRunSettings definieert een of meer logboekregistraties die moeten worden gebruikt voor de testuitvoering. De meest voorkomende logboekregistraties zijn console, Visual Studio Test Results File (trx) en 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>

MSTest-element

Deze instellingen zijn specifiek voor de testadapter die testmethoden uitvoert die het kenmerk TestMethodAttribute hebben.

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

Configuratie	Verstek	Waarden
GedwongenVerouderdeModus	vals	In oudere versies van Visual Studio is de MSTest-adapter geoptimaliseerd om deze sneller en beter schaalbaar te maken. Sommige gedragingen, zoals de volgorde waarin tests worden uitgevoerd, zijn mogelijk niet precies zoals in eerdere edities van Visual Studio. Stel de waarde in op true om de oudere testadapter te gebruiken. U kunt deze instelling bijvoorbeeld gebruiken als u een app.config bestand hebt opgegeven voor een eenheidstest. U wordt aangeraden uw tests te herstructureren zodat u de nieuwere adapter kunt gebruiken.
Instellingenbestand		U kunt hier een testinstellingenbestand opgeven dat moet worden gebruikt met de MSTest-adapter. U kunt ook een bestand met testinstellingen opgeven in het instellingenmenu. Als u deze waarde opgeeft, moet u ook de ForcedLegacyMode- instellen op true. `<ForcedLegacyMode>true</ForcedLegacyMode>`
DeploymentEnabled-	waar	Als u de waarde instelt op onwaar, worden implementatie-items die u in uw testmethode hebt opgegeven, niet gekopieerd naar de implementatiemap.
CaptureTraceOutput-	waar	Leg sms-berichten vast die afkomstig zijn van `Console.Write`, `Trace.Write`, `Debug.Write*`-API die wordt gekoppeld aan de huidige actieve test.
EnableBaseClassTestMethodsFromOtherAssemblies	waar	Een waarde die aangeeft of detectie van testmethoden uit basisklassen in een andere assembly moet worden ingeschakeld dan de overnemende testklasse.
ClassCleanupLifecycle	EndOfClass	Als u wilt dat de klasse wordt opgeschoond aan het einde van de assembly, stelt u deze in op EndOfAssembly-. (Niet meer ondersteund vanaf MSTest v4 omdat EndOfClass de standaardinstelling is en alleen ClassCleanup gedrag)
MislukteNietUitvoerbareKoppeling	waar	Een waarde die aangeeft of een niet-uitvoerbaar resultaat is gekoppeld aan een mislukte test.
paralleliseren	Wordt gebruikt om de instellingen voor parallelle uitvoering in te stellen: Workers: het aantal threads/werkrollen dat moet worden gebruikt voor parallelle uitvoering. Dit is standaard het aantal processors op de huidige computer. SCOPE: het bereik van parallelle uitvoering. U kunt deze instellen op MethodLevel. Het is standaard ClassLevel. `<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>`
TestTimeout	0	De opgegeven time-out voor globale testcases wordt opgehaald.
TreatDiscoveryWarningsAsErrors	onwaar	Als u detectiewaarschuwingen wilt rapporteren als fouten, stelt u deze waarde in op true.
TreatClassAndAssemblyCleanupWarningsAsErrors	vals	Als u uw fouten in klasseopruimingen als ernstige fouten wilt beschouwen, stelt u deze waarde in op waar.
DeployTestSourceDependencies	waar	Een waarde die aangeeft of de bronverwijzingen voor de test moeten worden geïmplementeerd.
DeleteDeploymentDirectoryAfterTestRunIsComplete	waar	Als u de implementatiemap wilt behouden na een testuitvoering, stelt u deze waarde in op false.
MapInconclusiveToFailed	vals	Als een test voltooid is met een inconclusieve status, wordt deze toegewezen aan de overgeslagen status in Test Explorer. Als u niet-overtuigende tests wilt weergeven als mislukt, stelt u de waarde in op true.
BeschouwFixturesAlsSpecialeTests	onwaar	Als u `AssemblyInitialize`, `AssemblyCleanup`, `ClassInitialize`wilt weergeven, `ClassCleanup` als afzonderlijke vermeldingen in Visual Studio en Visual Studio Code `Test Explorer` en `.trx` logboek, stelt u deze waarde in op true
Vergaderingsresolutie	vals	U kunt paden naar extra assembly's opgeven bij het zoeken en uitvoeren van eenheidstests. Gebruik deze paden bijvoorbeeld voor afhankelijkheidsassembly's die zich niet in dezelfde map bevinden als de testassembly. Om een pad op te geven, gebruikt u een Directorypad element. Paden kunnen omgevingsvariabelen bevatten. `<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>` Houd er rekening mee dat deze functie alleen wordt toegepast wanneer u .NET Framework-doel gebruikt.

Voorbeeld van .runsettings-bestand

In de volgende XML ziet u de inhoud van een typisch .runsettings--bestand. Kopieer deze code en bewerk deze naar wens.

Elk element van het bestand is optioneel omdat het een standaardwaarde heeft.

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

Omgevingsvariabelen opgeven in het bestand .runsettings

Omgevingsvariabelen kunnen worden ingesteld in het bestand .runsettings, die rechtstreeks met de testhost kunnen communiceren. Het opgeven van omgevingsvariabelen in het bestand .runsettings bestand is nodig om niet-triviale projecten te ondersteunen waarvoor omgevingsvariabelen moeten worden ingesteld, zoals DOTNET_ROOT. Deze variabelen worden ingesteld tijdens het instellen van het testhostproces en ze zijn beschikbaar in de host.

Voorbeeld

De volgende code is een voorbeeld van .runsettings--bestand dat omgevingsvariabelen doorgeeft:

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

Het knooppunt RunConfiguration moet een EnvironmentVariables-knooppunt bevatten. Een omgevingsvariabele kan worden opgegeven als een elementnaam en de bijbehorende waarde.

Notitie

Omdat deze omgevingsvariabelen altijd moeten worden ingesteld wanneer de testhost wordt gestart, moeten de tests altijd in een afzonderlijk proces worden uitgevoerd. Hiervoor wordt de vlag /InIsolation ingesteld wanneer er omgevingsvariabelen zijn, zodat de testhost altijd wordt aangeroepen.

Delen via

Eenheidstests configureren met behulp van een .runsettings-bestand

Een bestand met uitvoeringsinstellingen maken en aanpassen

Een bestand met uitvoeringsinstellingen opgeven in de IDE

Visual Studio 2019 versie 16.4 en hoger

Het bestand met uitvoeringsinstellingen automatisch detecteren

Selecteer handmatig het bestand met uitvoeringsinstellingen

Een build-eigenschap instellen

Visual Studio 2019 versie 16.3 en eerder

Een bestand met uitvoeringsinstellingen opgeven vanaf de opdrachtregel

Het bestand *.runsettings

RunConfiguration-element

Het element 'DataCollectors' (diagnostische gegevensadapters)

CodeCoverage-gegevensverzamelaar

VideoRecorder-gegevensverzamelaar

Gegevensverzamelaar de schuld geven

TestRunParameters

Het element LoggerRunSettings

MSTest-element

Voorbeeld van .runsettings-bestand

Omgevingsvariabelen opgeven in het bestand .runsettings

Voorbeeld

Feedback

Aanvullende resources

Delen via

Eenheidstests configureren met behulp van een .runsettings-bestand

Een bestand met uitvoeringsinstellingen maken en aanpassen

Een bestand met uitvoeringsinstellingen opgeven in de IDE

Visual Studio 2019 versie 16.4 en hoger

Het bestand met uitvoeringsinstellingen automatisch detecteren

Selecteer handmatig het bestand met uitvoeringsinstellingen

Een build-eigenschap instellen

Visual Studio 2019 versie 16.3 en eerder

Een bestand met uitvoeringsinstellingen opgeven vanaf de opdrachtregel

Het bestand *.runsettings

RunConfiguration-element

Het element 'DataCollectors' (diagnostische gegevensadapters)

CodeCoverage-gegevensverzamelaar

VideoRecorder-gegevensverzamelaar

Gegevensverzamelaar de schuld geven

TestRunParameters

Het element LoggerRunSettings

MSTest-element

Voorbeeld van .runsettings-bestand

Omgevingsvariabelen opgeven in het bestand .runsettings

Voorbeeld

Verwante inhoud

Feedback

Aanvullende resources