Konfigurieren von Komponententests mithilfe einer RUNSETTINGS-Datei
Eine RUNSETTINGS-Datei kann verwendet werden, um die Ausführung von Komponententests zu konfigurieren. Beispielsweise können darin die .NET-Version, in der die Tests ausgeführt werden, das Verzeichnis für die Testergebnisse sowie die während eines Testlaufs erfassten Daten geändert werden. RUNSETTINGS-Dateien werden häufig verwendet, um die Code Coverage-Analyse anzupassen.
Lautzeiteinstellungsdateien können zum Konfigurieren von Tests verwendet werden, die über die Befehlszeile, in der IDE oder in einem Buildworkflow mit Azure Test Plans oder Azure DevOps Server (ehemals Team Foundation Server [TFS]) ausgeführt werden.
Laufzeiteinstellungsdateien sind optional. Wenn keine spezielle Konfiguration erforderlich sein soll, benötigen Sie keine RUNSETTINGS-Datei.
Erstellen und Anpassen einer Laufzeiteinstellungsdatei
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.
Wenn nicht alle Elementvorlagen angezeigt werden, wählen Sie Alle Vorlagen anzeigen und dann die Elementvorlage aus.
Tipp
Der Dateiname spielt keine Rolle, sofern Sie die Erweiterung .runsettings verwenden.
Fügen Sie den Inhalt aus der *.runsettings-Beispieldatei hinzu, und passen Sie ihn dann entsprechend Ihrer Anforderungen in den folgenden Abschnitten an.
Geben Sie mithilfe einer der folgenden Methoden die gewünschte *.runsettings-Datei an:
- Visual Studio-IDE
- Befehlszeile
- Buildworkflow über Azure Test Plans oder Azure DevOps Server (ehemals Team Foundation Server [TFS]).
Führen Sie die Komponententests aus, damit die benutzerdefinierten Laufzeiteinstellungen verwendet werden.
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.
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
- Manuelles Festlegen der Laufzeiteinstellungen
- Festlegen einer Buildeigenschaft
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:
Wählen Sie Tools>Optionen>Test>RUNSETTINGS-Dateien automatisch erkennen
Wählen Sie Test>Laufzeiteinstellungen konfigurieren>RUNSETTINGS-Dateien automatisch erkennen
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.
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.
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.
Öffnen Sie die Developer-Eingabeaufforderung für Visual Studio.
Geben Sie einen Befehl wie diesen ein:
vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettingsoder
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>
<TestCaseFilter>(TestCategory != Integration) & (TestCategory != UnfinishedFeature)</TestCaseFilter>
<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 erzwingt nicht, dass Tests in den einzelnen Test-DLLs 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 lautet 1, was bedeutet, dass immer nur ein Testhost 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 Anzahl der unterschiedlichen DLLs in der Ausführung bestimmt die tatsächliche Anzahl der gestarteten Testhosts. |
| 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 (oder genauer gesagt runtimeconfig.json) festgelegt.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. Wird eine andere Version derselben Zielframeworkfamilie gefunden, 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. | |
| 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, 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 Ihre eigene Dotnet-Instanz erstellen, z. B. beim Erstellen des Repositorys „dotnet/runtime“. Durch die Angabe dieser Option wird die Suche nach „testhost.exe“ übersprungen und die Verwendung von „testhost.dll“ erzwungen. | |
| TreatNoTestsAsError | false | TRUE oder FALSE Geben Sie einen booleschen Wert an, der den Exitcode 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 (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.
Sie können Blame in drei verschiedenen Modi ausführen:
- 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 im <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>
TestRunParameters
<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 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 älteren Versionen von Visual Studio 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 den 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. |
| 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 truefestlegen. <ForcedLegacyMode>true</ForcedLegacyMode> |
|
| DeploymentEnabled | true | Wenn Sie den Wert auf FALSE festlegen, werden in der Testmethode angegebene Bereitstellungselemente nicht in das Bereitstellungsverzeichnis kopiert. |
| CaptureTraceOutput | true | Erfassen von Textnachrichten, die von Console.Write*-, Trace.Write*-, Debug.Write*-Api kommen und mit dem aktuell laufenden Test verknüpft werden. |
| EnableBaseClassTestMethodsFromOtherAssemblies | true | Ein Wert, der angibt, ob die Ermittlung von Testmethoden aus Basisklassen in einer anderen Assembly als der geerbten Testklasse aktiviert werden soll. |
| ClassCleanupLifecycle | EndOfClass | Wenn die Klassenbereinigung am Ende der Assembly erfolgen soll, legen Sie den Wert auf EndOfAssembly fest. (Wird ab MSTest 4 nicht mehr unterstützt, da EndOfClass das Standardverhalten und auch das einzige Verhalten für ClassCleanup ist.) |
| MapNotRunnableToFailed | true | Ein Wert, der angibt, ob einem Test mit Fehler ein „Nicht ausführbar“-Ergebnis zugeordnet wird. |
| Parallelize | Wird verwendet, um die Parallelisierungseinstellungen festzulegen: Workers: 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 dies auf MethodLevel festlegen. Die Standardeinstellung ist jedoch ClassLevel. <Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize> |
|
| TestTimeout | 0 | Ruft das angegebene globale Testfalltimeout ab. |
| TreatDiscoveryWarningsAsErrors | false | Wenn Sie Testerkennungswarnungen als Fehler melden möchten, legen Sie diesen Wert auf true fest. |
| TreatClassAndAssemblyCleanupWarningsAsErrors | false | 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 | Legen Sie diesen Wert auf FALSE fest, um das Bereitstellungsverzeichnis nach einem Testlauf beizubehalten. |
| MapInconclusiveToFailed | False | Wird ein Test mit einem nicht eindeutigen Status abgeschlossen, wird er im Test-Explorer dem Status „Übersprungen“ zugeordnet. Wenn nicht eindeutige Tests als fehlerhaft angezeigt werden sollen, verwenden Sie den Wert TRUE. |
| 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>Beachten Sie, dass dieses Feature nur bei Verwendung von .NET Framework als Ziel angewendet wird. |
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>
<!-- TestCaseFilter expression -->
<TestCaseFilter>(TestCategory != Integration) & (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. 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 beim Erzeugen des Testhostprozesses festgelegt, und sie sind im Host verfügbar.
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.
Zugehöriger Inhalt
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für