Konfigurieren von Komponententests mithilfe einer .runsettings-Datei

Artikel
02/03/2025

Eine .runsettings Datei kann verwendet werden, um zu konfigurieren, wie Komponententests ausgeführt werden. Beispielsweise kann sie verwendet werden, um die .NET-Version zu ändern, auf der die Tests ausgeführt werden, das Verzeichnis für die Testergebnisse oder die Daten, die während einer Testausführung gesammelt werden. RUNSETTINGS-Dateien werden häufig verwendet, um die Code Coverage-Analyse anzupassen.

Runsettings-Dateien können verwendet werden, um Tests zu konfigurieren, die über die Befehlszeile, aus der IDE oder in einem Build-Workflow mithilfe von Azure Test Plänen oder dem Azure DevOps Server (früher als Team Foundation Server (TFS) bezeichnet) ausgeführt werden.

Runsettings-Dateien sind optional. Wenn Sie keine spezielle Konfiguration benötigen, benötigen Sie keine .runsettings Datei.

Erstellen einer Ausführungseinstellungsdatei und Anpassen der Datei

Fügen Sie Ihrer Lösung eine Ausführungseinstellungsdatei hinzu. Wählen sie im Projektmappen-Explorer im Kontextmenü Ihrer Projektmappe die Option Hinzufügen>Neues Element und XML-Datei aus. Speichern Sie die Datei mit einem Namen wie test.runsettings.

Wenn nicht alle Elementvorlagen angezeigt werden, wählen Sie Alle Vorlagen anzeigenaus, und wählen Sie dann die Elementvorlage aus.

Tipp

Der Dateiname spielt keine Rolle, solange Sie die Erweiterung .runsettingsverwenden.
Fügen Sie den Inhalt aus Beispieldatei "*.runsettings"hinzu, und passen Sie ihn dann an Ihre Anforderungen an, wie in den folgenden Abschnitten beschrieben.
Geben Sie die datei *.runsettings an, die Sie mit einer der folgenden Methoden verwenden möchten:
- Visual Studio-IDE
- Befehlszeile
- Erstellen von Workflows mit Azure TestPlänen oder Azure DevOps Server (früher als Team Foundation Server (TFS) bezeichnet).
Führen Sie die Komponententests aus, um die benutzerdefinierten Ausführungseinstellungen zu verwenden.

Deaktivieren oder aktivieren Sie die Datei im Menü Test, um die benutzerdefinierten Einstellungen über die IDE ein- und auszuschalten.

Tipp

Sie können mehrere .runsettings Datei in Ihrer Lösung erstellen und bei Bedarf als aktive Testeinstellungsdatei auswählen.

Angeben einer Ausführungseinstellungsdatei in der IDE

Die verfügbaren Methoden hängen von Ihrer Version von Visual Studio ab.

Visual Studio 2019, Version 16.4 und höher

Es gibt drei Möglichkeiten zum Angeben einer Ausführungseinstellungsdatei in Visual Studio 2019, Version 16.4 und höher.

Automatische Erkennung der Ausführungseinstellungen
Manuelles Festlegen der Ausführungseinstellungen
Festlegen einer Buildeigenschaft

Automatisches Ermitteln der Datei mit den Ausführungseinstellungen

Anmerkung

Dies funktioniert nur für eine Datei mit dem Namen .runsettings.

Wenn Sie die Datei mit den Ausführungseinstellungen automatisch ermitteln möchten, platzieren Sie sie im Stammverzeichnis Ihrer Lösung.

Wenn die automatische Erkennung von Ausführungseinstellungsdateien aktiviert ist, werden die Einstellungen in dieser Datei für alle Tests angewendet. Sie können die automatische Erkennung von Runsettings-Dateien mit zwei Methoden aktivieren:

Wählen Sie Extras>Optionen>Test>RUNSETTINGS-Dateien automatisch erkennen aus.
Wählen Sie Test>Ausführungseinstellungen konfigurieren>RUNSETTINGS-Dateien automatisch erkennen aus.

Wählen Sie die Einstellungsdatei für die Ausführung manuell aus.

Wählen Sie in der IDE Test>"Ausführungseinstellungen konfigurieren">"Lösungsweite Runsettings"-Dateiaus, und wählen Sie dann die ".runsettings"-Datei aus.

Diese Datei setzt die .runsettings Datei im Stammverzeichnis der Lösung, falls vorhanden, außer Kraft und wird auf alle durchgeführten Tests angewendet.
Diese Dateiauswahl bleibt nur lokal erhalten.

Auswählen des Menüs „Projektmappenübergreifende RUNSETTINGS-Datei testen“ in Visual Studio

Festlegen einer Buildeigenschaft

Fügen Sie einem Projekt eine Buildeigenschaft über die Projektdatei oder eine Datei "Directory.Build.props" hinzu. Die Datei mit Ausführungseinstellungen für ein Projekt wird durch die Eigenschaft RunSettingsFilePath angegeben.

Laufzeiteinstellungen auf Projektebene werden derzeit in C#-, VB-, C++- und F#-Projekten unterstützt.
Eine für ein Projekt angegebene Datei setzt alle anderen Ausführungseinstellungsdateien außer Kraft, die in der Lösung angegeben sind.
Diese MSBuild-Eigenschaften können verwendet werden, um den Pfad zur Runsettings-Datei anzugeben.

Beispiel für die Angabe einer .runsettings-Datei für ein Projekt:

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

Visual Studio 2019, Version 16.3 und früher

Wählen Sie Test>Einstellungsdatei auswählen aus, um eine Ausführungseinstellungsdatei in der IDE anzugeben. Navigieren Sie zu der .runsettings Datei, und wählen Sie sie aus.

Auswählen des Menüs „Einstellungsdatei testen“ in Visual Studio 2019

Die Datei wird im Menü "Test" angezeigt, und Sie können sie auswählen oder deaktivieren. Wenn die Ausführungseinstellungsdatei ausgewählt ist, wird sie bei jeder Auswahl von Code Coverage analysieren angewendet.

Angeben einer Ausführungseinstellungsdatei über die Befehlszeile

Um Tests über die Befehlszeile auszuführen, verwenden Sie vstest.console.exe, und geben Sie die Einstellungsdatei mithilfe des parameters /Settings an.

Öffnen Sie die Developer-Eingabeaufforderung für Visual Studio.

Geben Sie einen Ähnlichen Befehl ein:

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

oder

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

Weitere Informationen finden Sie unter VSTest.Console.exe Befehlszeilenoptionen.

Die Datei "*.runsettings"

Die Datei "*.runsettings" ist eine XML-Datei, die unterschiedliche Konfigurationselemente innerhalb des RunSettings--Elements enthält. Die folgenden Abschnitte enthalten details zu den verschiedenen Elementen. Ein vollständiges Codebeispiel finden Sie unter *.runsettings-Beispieldatei.

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

Jedes der Konfigurationselemente ist optional, da es über einen Standardwert verfügt.

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>

Das RunConfiguration--Element kann die folgenden Elemente enthalten:

Knoten	Standard	Werte
MaxCpuCount	1	Der Optionsname ist case-sensitiv und kann leicht als MaxCPUCount falsch geschrieben werden. Diese Einstellung steuert die Parallelitätsebene auf Prozessebene. Verwenden Sie "0", um die maximale Parallelität auf Prozessebene zu ermöglichen. Diese Einstellung bestimmt die maximale Anzahl von Test-DLLs oder andere Testcontainer, die parallel ausgeführt werden können. Jede DLL wird in einem eigenen Testhost-Prozess ausgeführt und ist auf der Prozessebene von den Tests in anderen Test-DLLs isoliert. Diese Einstellung erzwingt nicht die Parallelausführung von Tests in jeder Test-DLL. Das Steuern der parallelen Ausführung innerhalb einer DLL (auf Threadebene) liegt bei dem Testframework wie MSTest, XUnit oder NUnit. Der Standardwert ist `1`, was bedeutet, dass nur ein Testhost gleichzeitig ausgeführt wird. Ein besonderer Wert `0` ermöglicht so viele Testhosts wie logische Prozessoren (z. B. 6, für einen Computer mit 6 physischen Kernen ohne Multithreading oder 12 für einen Computer mit sechs physischen Kernen mit Multithreading). Die Anzahl der eindeutigen DLLs in der Ausführung bestimmt die tatsächliche Anzahl der gestarteten Testhosts.
ResultsDirectory		Das Verzeichnis, in dem Testergebnisse platziert werden. Der Pfad ist relativ zum Verzeichnis, das die RUNSETTINGS-Datei enthält.
TargetFrameworkVersion	net40 oder netcoreapp1.0	Ganzes Tag für die automatische Erkennung auslassen Diese Einstellung definiert die Frameworkversion oder Die Frameworkfamilie, die zum Ausführen von Tests verwendet werden soll. Akzeptierte Werte sind alle Framework-Moniker wie `net48`, `net472`,`net6.0`, `net5.0`, `netcoreapp3.1`, `uap10.0` oder ein gültiger vollständiger Frameworkname wie`.NETFramework,Version=v4.7.2` oder `.NETCoreApp,Version=v6.0.0`. Aus Gründen der Abwärtskompatibilität werden `Framework35`, `Framework40`, `Framework45`, `FrameworkCore10`, `FrameworkUap10` akzeptiert, d. h. (`net35`, `net40`, `net45`, `netcoreapp1.0` bzw. `uap10.0`). Bei allen Werten wird die Groß-/Kleinschreibung nicht beachtet. Der bereitgestellte Wert wird verwendet, um den zu verwendenden Testlaufzeitanbieter zu ermitteln. Jeder Testlaufzeitanbieter muss die zu verwendende Frameworkfamilie respektieren, aber möglicherweise nicht die genaue Frameworkversion beachten: Für .NET Framework 4.5.1 - 4.8 wird ein Testhost verwendet, der mit der angegebenen genauen Version erstellt wurde. Für Werte außerhalb dieses Bereichs wird .NET Framework 4.5.1 testhost verwendet. Für .NET bestimmt die `<TargetFramework>` des Testprojekts (oder genauer `runtimeconfig.json`) die tatsächliche Version. Für UWP ist die Testprojektanwendung selbst ein Testhost und bestimmt die tatsächliche Version von UWP, die verwendet wird. Lassen Sie das `TargetFrameworkVersion`-Element aus der .runsettings-Datei aus, um die Frameworkversion automatisch aus den erstellten Binärdateien zu ermitteln. Bei der automatischen Erkennung werden alle Zielframeworks in einem einzigen gemeinsamen Framework vereinheitlicht. Wenn eine andere Version der gleichen Zielframeworkfamilie gefunden wird, wird die neuere Version ausgewählt (z. B. net452, net472, net48 = net48). Für den .NET Framework-Runner (in Visual Studio oder „vstest.console.exe“ in der Developer-Befehlszeile) ist das allgemeine Zielframework net40. Für .NET runner (dotnet test + DLLs) wird das allgemeine Zielframework auf netcoreapp1.0 festgelegt.
TargetPlatform	x86	Ganzes Tag für die automatische Erkennung auslassen Diese Einstellung definiert die Architektur, die zum Ausführen von Tests verwendet werden soll. Mögliche Werte sind `x86`, `x64`, `ARM`, `ARM64`, `S390x`. Bei der automatischen Erkennung kann sich die Architektur für AnyCPU-DLLs je nach Runner unterscheiden. Für .NET Framework runner (in Visual Studio oder vstest.console.exe in der Befehlszeile "Entwicklertools") lautet der Standardwert x86. Für .NET runner (dotnet test) ist die aktuelle Prozessarchitektur der Standard.
TreatTestAdapterErrorsAsWarnings	FALSCH	falsch, wahr
TestAdaptersPaths		Ein oder mehrere Pfade zu dem Verzeichnis, in dem sich die TestAdapter befinden
TestCaseFilter		Ein Filterausdruck im Format <Eigenschaft><Operator><Wert>[\|&<Ausdruck>] Der boolesche Operator & sollte durch die HTML-Entität & dargestellt werden.. Ausdrücke können in Klammern eingeschlossen werden. Ausführliche Syntax zur Ausdrucksstruktur finden Sie unter vstest/docs/filter.md.
TestSessionTimeout		Ermöglicht Benutzern das Beenden einer Testsitzung, wenn sie ein bestimmtes Timeout überschreitet, das in Millisekunden angegeben ist. Durch das Festlegen eines Timeouts wird sichergestellt, dass Ressourcen gut genutzt werden und Testsitzungen auf eine festgelegte Zeit beschränkt sind. Die Einstellung ist in Visual Studio 2017, Version 15.5 und höher, verfügbar.
DotnetHostPath		Geben Sie einen benutzerdefinierten Pfad zu dotnet-Host an, der zum Ausführen des Testhosts verwendet wird. Es ist nützlich, wenn Sie Ein eigenes Dotnet erstellen, z. B. beim Erstellen des dotnet/runtime-Repositorys. Die Angabe dieser Option überspringt die Suche nach testhost.exeund erzwingt die Verwendung von testhost.dll.
TreatNoTestsAsError	FALSCH	wahr oder falsch Geben Sie einen booleschen Wert an, der den Beendigungscode definiert, wenn keine Tests erkannt werden. Wenn der Wert `true` lautet und keine Tests erkannt werden, wird ein Exitcode ungleich NULL zurückgegeben. Andernfalls wird Null zurückgegeben.

DataCollectors-Element (Diagnosedatenadapter)

Das DataCollectors--Element gibt Einstellungen von Diagnosedatenadaptern an. Diagnosedatenadapter sammeln zusätzliche Informationen über die Umgebung und die anwendung, die getestet wird. Jeder Adapter verfügt über Standardeinstellungen, und Sie müssen nur Einstellungen angeben, wenn Sie die Standardwerte nicht verwenden möchten.

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

CodeCoverage-Datensammler

Die Codeabdeckungsdatensammler erstellt ein Protokoll, das aufzeichnet, welche Teile des Anwendungscodes im Test ausgeführt wurden. Ausführliche Informationen zum Anpassen der Einstellungen für die Codeabdeckung finden Sie unter Anpassen der Codeabdeckungsanalyse.

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

Der Videodatensammler erfasst eine Bildschirmaufzeichnung, wenn Tests ausgeführt werden. Diese Aufzeichnung ist nützlich für die Problembehandlung bei UI-Tests. Der Videodatensammler ist in Visual Studio 2017, Version 15.5 und höher, verfügbar. Ein Beispiel zum Konfigurieren dieses Datensammlers finden Sie in der Beispieldatei *.runsettings.

Verwenden Sie zum Anpassen aller anderen Arten von Diagnosedatenadaptern eine -Testeinstellungsdatei.

Schuldzuweisung an den Datensammler

Mit dieser Option können Sie einen problematischen Test isolieren, der zu einem Testhostabsturz führt. Wenn Sie den Sammelsammler ausführen, wird eine Ausgabedatei (Sequence.xml) in TestResultserstellt, die die Reihenfolge der Ausführung des Tests vor dem Absturz erfasst.

Sie können den Befehl "blame" in drei verschiedenen Modi nutzen.

Sequenzdateimodus: Erstellt eine Datei mit der Liste der Tests bis zum Systemstillstand
Absturzabbildmodus: Erstellt beim Absturz des Testhosts ein Absturzabbild.
Stillstandabbildmodus: Erstellt ein Speicherabbild, wenn der Test nicht vor Ablauf eines bestimmten Zeitlimits abgeschlossen wird

Die XML-Konfiguration sollte direkt in den <RunSettings>-Knoten platziert werden.

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

Testlaufparameter

<TestRunParameters>
    <Parameter name="webAppUrl" value="http://localhost" />
    <Parameter name="docsUrl" value="https://learn.microsoft.com" />
</TestRunParameters>

Testlaufparameter bieten eine Möglichkeit zum Definieren von Variablen und Werten, die zur Laufzeit für die Tests verfügbar sind. Zugreifen auf die Parameter mithilfe der MSTest-TestContext.Properties-Eigenschaft (oder der NUnit TestContext):

public TestContext TestContext { get; set; }

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

Um Testausführungsparameter zu verwenden, fügen Sie ihrer Testklasse eine öffentliche TestContext-Eigenschaft hinzu.

LoggerRunSettings-Element

Der abschnitt LoggerRunSettings definiert einen oder mehrere Logger, die für die Testausführung verwendet werden sollen. Die am häufigsten verwendeten Logger sind Konsole, Visual Studio Test Results File (trx) und 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

Diese Einstellungen sind spezifisch für den Testadapter, der Testmethoden ausführt, die das attribut TestMethodAttribute aufweisen.

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

Konfiguration	Standard	Werte
ForcedLegacyMode	FALSCH	In älteren Versionen von Visual Studio wurde der MSTest-Adapter optimiert, um ihn schneller und skalierbarer zu machen. Einige Verhaltensweisen, z. B. die Reihenfolge, in der Tests ausgeführt werden, sind möglicherweise nicht genau wie in früheren Editionen von Visual Studio. Legen Sie den Wert auf true fest, um den älteren Testadapter zu verwenden. Sie können diese Einstellung beispielsweise verwenden, wenn Sie eine app.config Datei für einen Komponententest angegeben haben. Es wird empfohlen, ihre Tests umzugestalten, damit Sie den neueren Adapter verwenden können.
SettingsFile		Sie können hier eine Testeinstellungsdatei angeben, die mit dem MSTest-Adapter verwendet werden soll. Sie können auch eine Testeinstellungsdatei aus dem Menü "Einstellungen"angeben. Wenn Sie diesen Wert angeben, müssen Sie außerdem ForcedLegacyMode auf TRUE festlegen. `<ForcedLegacyMode>true</ForcedLegacyMode>`
DeploymentEnabled	TRUE	Wenn Sie den Wert auf falsefestlegen, werden bereitstellungselemente, die Sie in Der Testmethode angegeben haben, nicht in das Bereitstellungsverzeichnis kopiert.
CaptureTraceOutput	TRUE	Erfassen Sie Textnachrichten, die von der `Console.Write`-, `Trace.Write`-, `Debug.Write*`-API stammen und dem aktuell ausgeführten Test zugeordnet werden.
EnableBaseClassTestMethodsFromOtherAssemblies	TRUE	Ein Wert, der angibt, ob die Ermittlung von Testmethoden aus Basisklassen in einer anderen Assembly als die geerbte Testklasse ermöglicht werden soll.
ClassCleanupLifecycle	EndOfClass	Wenn die Klassenbereinigung am Ende der Assembly erfolgen soll, legen Sie den Wert auf EndOfAssembly fest. (Wird ab MSTest v4 nicht mehr unterstützt, da EndOfClass das Standardverhalten und auch das einzige Verhalten für ClassCleanup ist.)
MapNotRunnableToFailed	TRUE	Ein Wert, der angibt, ob ein nicht ausführbares Ergebnis einem fehlgeschlagenen Test zugeordnet wird.
Parallelisieren	Wird verwendet, um die Parallelisierungseinstellungen festzulegen: Worker: Die Anzahl der Threads/Worker, die für die Parallelisierung verwendet werden sollen. Dies ist standardmäßig die Anzahl von Prozessoren auf dem aktuellen Computer. SCOPE: Der Bereich der Parallelisierung. Sie können es auf MethodLevelfestlegen. Standardmäßig ist es ClassLevel-. `<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>`
TestTimeout	0	Ruft das angegebene globale Testfalltimeout ab
BehandleEntdeckungswarnungenAlsFehler	FALSCH	Wenn Sie Testerkennungswarnungen als Fehler melden möchten, legen Sie diesen Wert auf truefest.
TreatClassAndAssemblyCleanupWarningsAsErrors	FALSCH	Um Fehler in Klassenbereinigungen als Fehler anzuzeigen, legen Sie diesen Wert auf TRUE fest.
DeployTestSourceDependencies	TRUE	Ein Wert, der angibt, ob die Testquellverweise bereitgestellt werden sollen
DeleteDeploymentDirectoryAfterTestRunIsComplete	TRUE	Wenn Sie das Bereitstellungsverzeichnis nach einer Testausführung beibehalten möchten, legen Sie diesen Wert auf falsefest.
MapInconclusiveToFailed	FALSCH	Wenn ein Test mit einem unklaren Status abgeschlossen wird, wird er dem Status 'übersprungen' im Test Explorerzugeordnet. Wenn nicht abschließende Tests als fehlgeschlagen angezeigt werden sollen, legen Sie den Wert auf truefest.
ConsiderFixturesAsSpecialTests	FALSCH	Um `AssemblyInitialize`, `AssemblyCleanup`, `ClassInitialize`, `ClassCleanup` als einzelne Einträge in Visual Studio und Visual Studio Code `Test Explorer` und `.trx` Protokoll anzuzeigen, legen Sie diesen Wert auf true
AssemblyResolution	FALSCH	Sie können Beim Suchen und Ausführen von Komponententests Pfade zu zusätzlichen Assemblys angeben. Verwenden Sie beispielsweise diese Pfade für Abhängigkeitsassemblys, die sich nicht im selben Verzeichnis wie die Testassembly befinden. Verwenden Sie zum Angeben eines Pfads ein Verzeichnispfad--Element. Pfade können Umgebungsvariablen enthalten. `<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>` Beachten Sie, dass dieses Feature nur bei Verwendung des .NET Framework-Ziels angewendet wird.

Beispieldatei .runsettings

Der folgende XML-Code zeigt den Inhalt einer typischen .runsettings-Datei. Kopieren Sie diesen Code, und bearbeiten Sie ihn entsprechend Ihren Anforderungen.

Jedes Element der Datei ist optional, da es über einen Standardwert verfügt.

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

Angeben von Umgebungsvariablen in der .runsettings Datei

Umgebungsvariablen können in der .runsettings Datei festgelegt werden, die direkt mit dem Testhost interagieren kann. Das Angeben von Umgebungsvariablen in der .runsettings Datei ist erforderlich, um nichttriviale Projekte zu unterstützen, für die Umgebungsvariablen wie DOTNET_ROOTfestgelegt werden müssen. Diese Variablen werden beim Spawning des Testhostprozesses festgelegt und sind im Host verfügbar.

Beispiel

Der folgende Code ist ein Beispiel .runsettings Datei, die Umgebungsvariablen übergibt:

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

Der Knoten RunConfiguration muss einen EnvironmentVariables-Knoten enthalten. Eine Umgebungsvariable kann als Elementname und wert angegeben werden.

Anmerkung

Da diese Umgebungsvariablen immer festgelegt werden sollten, wenn der Testhost gestartet wird, sollten die Tests immer in einem separaten Prozess ausgeführt werden. Dazu wird das /InIsolation Flag festgelegt, wenn Umgebungsvariablen vorhanden sind, sodass der Testhost immer aufgerufen wird.

Freigeben über

Konfigurieren von Komponententests mithilfe einer .runsettings-Datei

Erstellen einer Ausführungseinstellungsdatei und Anpassen der Datei

Angeben einer Ausführungseinstellungsdatei in der IDE

Visual Studio 2019, Version 16.4 und höher

Automatisches Ermitteln der Datei mit den Ausführungseinstellungen

Wählen Sie die Einstellungsdatei für die Ausführung manuell aus.

Festlegen einer Buildeigenschaft

Visual Studio 2019, Version 16.3 und früher

Angeben einer Ausführungseinstellungsdatei über die Befehlszeile

Die Datei "*.runsettings"

RunConfiguration-Element

DataCollectors-Element (Diagnosedatenadapter)

CodeCoverage-Datensammler

VideoRecorder-Datensammler

Schuldzuweisung an den Datensammler

Testlaufparameter

LoggerRunSettings-Element

MSTest-Element

Beispieldatei .runsettings

Angeben von Umgebungsvariablen in der .runsettings Datei

Beispiel

Feedback

Zusätzliche Ressourcen

Freigeben über

Konfigurieren von Komponententests mithilfe einer .runsettings-Datei

Erstellen einer Ausführungseinstellungsdatei und Anpassen der Datei

Angeben einer Ausführungseinstellungsdatei in der IDE

Visual Studio 2019, Version 16.4 und höher

Automatisches Ermitteln der Datei mit den Ausführungseinstellungen

Wählen Sie die Einstellungsdatei für die Ausführung manuell aus.

Festlegen einer Buildeigenschaft

Visual Studio 2019, Version 16.3 und früher

Angeben einer Ausführungseinstellungsdatei über die Befehlszeile

Die Datei "*.runsettings"

RunConfiguration-Element

DataCollectors-Element (Diagnosedatenadapter)

CodeCoverage-Datensammler

VideoRecorder-Datensammler

Schuldzuweisung an den Datensammler

Testlaufparameter

LoggerRunSettings-Element

MSTest-Element

Beispieldatei .runsettings

Angeben von Umgebungsvariablen in der .runsettings Datei

Beispiel

Verwandte Inhalte

Feedback

Zusätzliche Ressourcen