Konfigurieren von Komponententests mithilfe einer RUNSETTINGS-Datei

Komponententests in Visual Studio können mithilfe einer RUNSETTINGS-Datei konfiguriert werden. Beispielsweise können Sie die .NET-Version, in der die Tests ausgeführt werden, das Verzeichnis für die Testergebnisse sowie die während eines Testlaufs erfassten Daten ändern. RUNSETTINGS-Dateien werden häufig verwendet, um die Code Coverage-Analyse anzupassen.

Laufzeiteinstellungsdateien können verwendet werden, um Tests zu konfigurieren, die über die Befehlszeile, in der IDE oder in einem Buildworkflow mit Azure Test Plans oder Team Foundation Server (TFS) ausgeführt werden.

Testlaufeinstellungsdateien sind optional. Wenn keine spezielle Konfiguration erforderlich sein soll, benötigen Sie keine RUNSETTINGS-Datei.

Erstellen und Anpassen einer Laufzeiteinstellungsdatei

  1. Fügen Sie eine Testlaufeinstellungsdatei zu Ihrer Projektmappe 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 unter einem Namen wie test.runsettings.

    Tipp

    Der Dateiname spielt keine Rolle, sofern Sie die Erweiterung .runsettings verwenden.

  2. Fügen Sie den Inhalt aus der *.runsettings-Beispieldatei hinzu, und passen Sie ihn dann entsprechend Ihrer Anforderungen in den folgenden Abschnitten an.

  3. Geben Sie mithilfe einer der folgenden Methoden die gewünschte *.runsettings-Datei an:

  4. Führen Sie die Komponententests aus, damit die benutzerdefinierten Laufzeiteinstellungen verwendet werden.

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

Testeinstellungsmenü mit benutzerdefinierter Einstellungsdatei in Visual Studio 2017

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-Dateien in Ihrer Projektmappe erstellen und je nach Bedarf eine davon als aktive Testeinstellungsdatei auswählen.

Angeben einer Testlaufeinstellungsdatei in der IDE

Die verfügbaren Methoden hängen von der jeweiligen Visual Studio-Version ab.

Um eine Testlaufeinstellungsdatei in der IDE anzugeben, wählen Sie Test > Testeinstellungen > Datei für Testeinstellungen auswählen und anschließend die .runsettings-Datei aus.

Menü „Datei für Testeinstellungen auswählen“ in Visual Studio 2017

Die Datei wird im Menü „Testeinstellungen“ angezeigt, und Sie können sie auswählen oder abwählen. Wenn die Testlaufeinstellungsdatei ausgewählt ist, wird sie bei jeder Auswahl von Code Coverage analysieren angewendet.

Visual Studio 2019, Version 16.4 und höher

Es gibt drei Möglichkeiten, in Visual Studio 2019, Version 16.4 und höher, eine Datei mit Laufzeiteinstellungen anzugeben.

Automatische Erkennung der Laufzeiteinstellungen

Hinweis

Dies funktioniert nur bei einer .runsettings-Datei.

Für eine automatische Erkennung der Laufzeiteinstellungsdatei platzieren Sie sie im Stammverzeichnis Ihrer Projektmappe.

Wenn die automatische Erkennung der Datei mit Laufzeiteinstellungen aktiviert ist, werden die Einstellungen in dieser Datei auf alle ausgeführten Tests angewendet. Sie können die automatische Erkennung der Datei mit Laufzeiteinstellungen über zwei Methoden aktivieren:

  • Klicken Sie auf Extras > Optionen > Test > RUNSETTINGS-Dateien automatisch ermitteln.

    Option für das automatische Erkennen einer RUNSETTINGS-Datei in Visual Studio

  • Klicken Sie auf Test > Laufzeiteinstellungen konfigurieren > RUNSETTINGS-Dateien automatisch ermitteln.

    Menü für das automatische Erkennen einer RUNSETTINGS-Datei in Visual Studio

Manuelles Auswählen der Laufzeiteinstellungsdatei

Wählen Sie in der IDE Test > Laufzeiteinstellungen konfigurieren > Lösungsweite RUNSETTINGS-Datei auswählen und anschließend die RUNSETTINGS-Datei aus.

  • Diese Datei überschreibt die RUNSETTINGS-Datei im Stammverzeichnis der Projektmappe, sofern diese vorhanden ist, und wird auf alle ausgeführten Testläufe angewendet.
  • Diese Dateiauswahl wird nur lokal beibehalten.

Menü „Lösungsweite RUNSETTINGS-Datei auswählen“ in Visual Studio

Festlegen einer Buildeigenschaft

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

  • Laufzeiteinstellungen auf Projektebene werden zurzeit in C#-, VB-, C++- und F#-Projekten unterstützt.
  • Eine für ein Projekt angegebene Datei setzt alle anderen in der Projektmappe angegebenen Laufzeiteinstellungen außer Kraft.
  • Mithilfe dieser MSBuild-Eigenschaften können Sie den Pfad zur RUNSETTINGS-Datei angeben.

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 Testlaufeinstellungsdatei anzugeben. Navigieren Sie zur .runsettings-Datei, und wählen Sie diese aus.

Menü „Datei für Testeinstellungen auswählen“ in Visual Studio 2019

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

Angeben einer Laufzeiteinstellungsdatei in der Befehlszeile

Verwenden Sie zum Ausführen von Tests über die Befehlszeile vstest.console.exe, und geben Sie die Einstellungsdatei mithilfe des Parameters /Settings an.

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

  2. Geben Sie einen Befehl wie diesen ein:

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

    oder

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

Weitere Informationen finden Sie unter Befehlszeilenoptionen von „VSTest.Console.exe“.

Die *.runsettings-Datei

Die *.runsettings-Datei ist eine XML-Datei, die verschiedene Konfigurationselemente innerhalb des RunSettings-Elements enthält. In den folgenden Abschnitten werden die verschiedenen Elemente beschrieben. Ein Codebeispiel finden Sie unter *.runsettings-Beispieldatei.

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

Alle Elemente des Konfigurationselements sind optional, da sie einen Standardwert enthalten.

RunConfiguration-Element

<RunConfiguration>
    <MaxCpuCount>1</MaxCpuCount>
    <ResultsDirectory>.\TestResults</ResultsDirectory>
    <TargetPlatform>x86</TargetPlatform>
    <TargetFrameworkVersion>net6.0</TargetFrameworkVersion>
    <TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
    <TestSessionTimeout>10000</TestSessionTimeout>
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>

Das RunConfiguration-Element kann folgende Elemente enthalten:

Knoten Standard Werte
MaxCpuCount 1 Beim Optionsnamen wird die Groß-/Kleinschreibung beachtet, und er kann leicht falsch geschrieben werden, z. B. MaxCPUCount.

Diese Einstellung steuert die Ebene der Parallelität auf Prozessebene. Verwenden Sie 0 (null), um die maximale Parallelität auf Prozessebene zu aktivieren.

Diese Einstellung bestimmt die maximale Anzahl von Test-DLLs oder anderen Testcontainern, die parallel ausgeführt werden können. Jede DLL wird in einem eigenen Testhostprozess ausgeführt und auf Prozessebene von den Tests in anderen Test-DLLs isoliert. Diese Einstellung erzwingen nicht, dass Tests in jeder Test-DLL parallel ausgeführt werden. Die Steuerung der parallelen Ausführung innerhalb einer DLL (auf Threadebene) liegt beim Testframework wie MSTest, XUnit oder NUnit.

Der Standardwert ist 1. Das bedeutet, dass nur ein Testhost gleichzeitig ausgeführt wird. Ein spezieller Wert 0 lässt so viele Testhosts zu, wie Sie über logische Prozessoren verfügen (z. B. sechs für einen Computer mit sechs physischen Kernen ohne Multithreading oder 12 für einen Computer mit sechs physischen Kernen mit Multithreading).

Die tatsächliche Anzahl von Testhosts, die gestartet werden, wird durch die Anzahl der unterschiedlichen DLLs während der Ausführung bestimmt.
ResultsDirectory Das Verzeichnis, in dem die Testergebnisse gespeichert werden. Der Pfad ist relativ zum Verzeichnis, das die RUNSETTINGS-Datei enthält.
TargetFrameworkVersion net40 oder netcoreapp1.0 Omit this whole tag to auto-detect. (Ganzes Tag für die automatische Erkennung auslassen)

Diese Einstellung definiert die Frameworkversion oder Frameworkfamilie, die zum Ausführen von Tests verwendet werden soll.

Akzeptierte Werte sind beliebige Frameworkmoniker wie net48, net472,net6.0, net5.0, netcoreapp3.1, uap10.0oder 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 und FrameworkUap10 akzeptiert, was jeweils net35, net40, net45, netcoreapp1.0 und uap10.0 bedeutet. Bei allen Werten wird die Groß-/Kleinschreibung nicht beachtet.

Der angegebene Wert wird verwendet, um den zu verwendenden Testlaufzeitanbieter zu bestimmen. Jeder Testlaufzeitanbieter muss die zu verwendende Frameworkfamilie, aber möglicherweise nicht die genaue Frameworkversion berücksichtigen:

Für .NET Framework 4.5.1 bis 4.8 wird ein Testhost verwendet, der mit der angegebenen genauen Version erstellt wurde. Für Werte außerhalb dieses Bereichs wird der .NET Framework 4.5.1-Testhost verwendet.

Für .NET wird die tatsächliche Version durch das <TargetFramework> des Testprojekts bestimmt (oder genauer gesagt runtimeconfig.json).

Für die universelle Windows-Plattform (UWP) ist die Testprojektanwendung selbst ein Testhost und bestimmt die tatsächliche Version der verwendeten UWP.

Lassen Sie das TargetFrameworkVersion-Element aus der .runsettings-Datei aus, um automatisch die Frameworkversion aus den erstellten Binärdateien zu bestimmen.

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 den .NET-Runner (dotnet test + DLLs) ist das allgemeine Zielframework auf netcoreapp1.0 festgelegt.
TargetPlatform x86 Omit this whole tag to auto-detect. (Ganzes Tag für die automatische Erkennung auslassen)

Diese Einstellung definiert die Architektur, die zum Ausführen von Tests verwendet werden soll. Die folgenden Werte sind möglich: x86, x64, ARM, ARM64 und S390x.

Bei der automatischen Erkennung kann sich die Architektur für AnyCPU-DLLs je nach Runner unterscheiden. Für den .NET Framework-Runner (in Visual Studio oder „vstest.console.exe“ in der Developer-Befehlszeile) ist der Standardwert x86. Für den .NET-Runner (dotnet test) ist der Standardwert die aktuelle Prozessarchitektur.

TreatTestAdapterErrorsAsWarnings False false, true
TestAdaptersPaths Ein oder mehrere Pfade zu dem Verzeichnis, in dem die Testadapter gespeichert sind.
TestSessionTimeout Ermöglicht Benutzern, eine Testsitzung zu beenden, wenn sie ein angegebenes Timeout überschreitet. Die Einstellung eines Timeouts stellt sicher, dass die Ressourcen gut ausgenutzt werden und Testsitzungen auf einen bestimmten Zeitraum beschränkt bleiben. Diese Einstellung ist in Visual Studio 2017 Version 15.5 und höher verfügbar.
DotnetHostPath Legen Sie einen benutzerdefinierten Pfad zum Dotnet-Host fest, der zum Ausführen des Testhosts verwendet wird. Dies ist hilfreich, wenn Sie Ihren eigenen Dotnet-Host erstellen, z. B. beim Erstellen des Repositorys „dotnet/runtime“. Wenn Sie diese Option festlegen, wird die Suche nach der Datei „testhost.exe“ übersprungen, und stattdessen wird die Datei „testhost.dll“ verwendet.
TreatNoTestsAsError false true oder false
Geben Sie einen booleschen Wert an, der den Exitcode definiert, wenn keine Tests erkannt werden. Wenn der Wert true ist und keine Tests erkannt werden, wird ein Exitcode ungleich null (0) zurückgegeben. Andernfalls wird Null zurückgegeben.

DataCollectors-Element (Adapter für diagnostische Daten)

Das DataCollectors-Element gibt die Einstellungen von Adaptern für diagnostische Daten an. Adapter für diagnostische Daten sammeln zusätzliche Informationen zur Umgebung und der getesteten Anwendung. Jeder Adapter verfügt über Standardeinstellungen. Wenn Sie diese nicht verwenden möchten, können Sie andere Einstellungen festlegen.

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

CodeCoverage-Datencollector

Der Datensammler der Codeabdeckung erstellt ein Protokoll der Teile des Anwendungscodes, die im Test ausgeführt wurden. Weitere Informationen zum Anpassen der Einstellungen für Code Coverage finden Sie unter Anpassen der Code Coverage-Analyse.

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

Der Videodatensammler erfasst einen Bildschirm bei der Ausführung von Tests. Diese Aufzeichnung kann zur Problembehandlung von Benutzeroberflächentests verwendet werden. Der Videodatensammler ist in Visual Studio 2017 Version 15.5 und höher verfügbar. Ein Beispiel für das Konfigurieren dieses Datencollectors finden Sie unter *.runsettings-Beispieldatei.

Um andere Typen von Adaptern für diagnostische Daten anzupassen, verwenden Sie eine Testeinstellungsdatei.

Datensammlung mit blame

Mit dieser Option können Sie einen problematischen Test isolieren, der zu einem Absturz des Testhosts führt. Wenn Sie den Collector ausführen, wird eine Ausgabedatei (Sequence.xml) in TestResults generiert, in der die Ausführungsreihenfolge des Tests vor dem Absturz erfasst wird.

<DataCollector friendlyName="blame" enabled="True">
</DataCollector>

TestRunParameters

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

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

private string _appUrl;
public TestContext TestContext { get; set; }

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

Fügen Sie Ihrer Testklasse eine öffentliche TestContext-Eigenschaft hinzu, um Testlaufparameter zu verwenden.

LoggerRunSettings-Element

Der Abschnitt LoggerRunSettings definiert eine oder mehrere Protokollierungen, die für den Testlauf verwendet werden. Die häufigsten Protokollierungen sind die Konsole, die Datei mit Testergebnissen in Visual Studio (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 betreffen den Testadapter, der Testmethoden ausführt, die über das TestMethodAttribute -Attribut verfügen.

<MSTest>
    <MapInconclusiveToFailed>True</MapInconclusiveToFailed>
    <CaptureTraceOutput>false</CaptureTraceOutput>
    <DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
    <DeploymentEnabled>False</DeploymentEnabled>
    <AssemblyResolution>
      <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
    </AssemblyResolution>
</MSTest>
Konfiguration Standard Werte
ForcedLegacyMode False In Visual Studio 2012 wurde der MSTest-Adapter für eine schnellere Geschwindigkeit und bessere Skalierbarkeit optimiert. Einige Verhalten, z. B. die Reihenfolge der Testausführung, sind möglicherweise nicht mehr so präzise wie in den vorherigen Versionen von Visual Studio. Legen Sie diesen Wert auf TRUE fest, um den älteren Testadapter zu verwenden.

Beispielsweise können Sie diese Einstellung verwenden, wenn Sie eine app.config-Datei für einen Komponententest angegeben haben.

Eventuell sollten Sie in Betracht ziehen, die Tests so umzugestalten, dass Sie den späteren Adapter verwenden können.
IgnoreTestImpact False Das Testauswirkungsfeature priorisiert Tests, auf die sich aktuelle Änderungen auswirken, wenn sie in MSTest oder über Microsoft Test Manager ausgeführt werden (ab Visual Studio 2017 veraltet). Diese Einstellung deaktiviert die Funktion. Weitere Informationen finden Sie unter Welche Tests sollten ab einem vorherigen Build ausgeführt werden?
SettingsFile Sie können eine Testeinstellungsdatei, die mit dem MS-Testadapter verwendet werden soll, hier angeben. Sie können auch eine Testeinstellungsdatei im Menü „Einstellungen“ angeben.

Wenn Sie diesen Wert angeben, müssen Sie außerdem ForcedLegacyMode auf true festlegen.

<ForcedLegacyMode>true</ForcedLegacyMode>
KeepExecutorAliveAfterLegacyRun False Nachdem ein Testlauf abgeschlossen ist, wird MSTest beendet. Jeder Prozess, der als Teil des Tests gestartet wird, wird dann ebenfalls abgebrochen. Wenn der Test-Executor aktiv bleiben soll, legen Sie den Wert auf TRUE fest. Beispielsweise können Sie mit dieser Einstellung erreichen, dass der Browser zwischen Tests der programmierten UI aktiv bleibt.
DeploymentEnabled true Wenn Sie den Wert auf FALSE festlegen, werden in der Testmethode angegebene Bereitstellungselemente nicht in das Bereitstellungsverzeichnis kopiert.
CaptureTraceOutput true Mithilfe von Trace.WriteLine können Sie über Ihre Testmethode in die Debugablaufverfolgung schreiben.
DeleteDeploymentDirectoryAfterTestRunIsComplete true Legen Sie diesen Wert auf FALSE fest, um das Bereitstellungsverzeichnis nach einem Testlauf beizubehalten.
MapInconclusiveToFailed False Wenn ein Test mit einem nicht eindeutigen Status abgeschlossen wird, wird er im Test-Explorer dem Status „Übersprungen“ zugeordnet. Wenn nicht eindeutige Tests als fehlerhaft angezeigt werden sollen, verwenden Sie den Wert TRUE.
InProcMode False Wenn die Tests im selben Prozess wie der MSTest-Adapter ausgeführt werden sollen, legen Sie diesen Wert auf true fest. Diese Einstellung führt zu einer geringen Leistungssteigerung. Wenn ein Test allerdings mit einer Ausnahme beendet wird, werden die restlichen Tests nicht ausgeführt.
AssemblyResolution False Sie können Pfade zu weiteren Assemblys angeben, wenn Komponententests gefunden und ausgeführt werden. Verwenden Sie diese Pfade beispielsweise für Abhängigkeitsassemblys, die sich nicht im selben Verzeichnis wie die Testassembly befinden. Um einen Pfad anzugeben, verwenden Sie ein Directory Path-Element. Pfade können Umgebungsvariablen enthalten.

<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>

Beispiel für eine RUNSETTINGS-Datei

Der folgende XML-Code ist ein Beispiel für den Inhalt einer typischen RUNSETTINGS-Datei. Kopieren Sie diesen Code, und passen Sie ihn Ihren Anforderungen entsprechend an.

Alle Elemente der Datei sind optional, da sie einen Standardwert enthalten.

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

    <!-- 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. Sie müssen Umgebungsvariablen in der RUNSETTINGS-Datei angeben, um nicht triviale Projekte zu unterstützen, für die Umgebungsvariablen wie DOTNET_ROOT festgelegt werden müssen. Diese Variablen werden festgelegt, wenn der Testhostprozess erzeugt wird und diese im Host verfügbar sind.

Beispiel

Der folgende Code entspricht einer RUNSETTINGS-Beispieldatei, die eine Umgebungsvariable ü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.

Hinweis

Da diese Umgebungsvariablen immer beim Start des Testhosts festgelegt werden sollten, sollten die Tests immer in einem separaten Prozess ausgeführt werden. Hierfür wird das Flag /InIsolation festgelegt, wenn Umgebungsvariablen vorhanden sind, sodass der Testhost immer aufgerufen wird.

Siehe auch