Configurer des tests unitaires à l’aide d’un fichier .runsettings

Article
02/03/2025

Un fichier .runsettings peut être utilisé pour configurer la façon dont les tests unitaires sont exécutés. Par exemple, il peut être utilisé pour modifier la version .NET sur laquelle les tests sont exécutés, le répertoire des résultats des tests ou les données collectées pendant une exécution de test. Une utilisation courante d’un fichier .runsettings est de personnaliser l’analyse de la couverture du code.

Les fichiers Runsettings peuvent être utilisés pour configurer des tests exécutés à partir de la ligne de commande , à partir de l’IDE ou dans un workflow de génération à l’aide d’Azure Test Plans ou d’Azure DevOps Server (anciennement Team Foundation Server (TFS)).

Les fichiers Runsettings sont facultatifs. Si vous n’avez pas besoin d’une configuration spéciale, vous n’avez pas besoin d’un fichier .runsettings.

Créer un fichier de paramètres d’exécution et le personnaliser

Ajoutez un fichier de paramètres d’exécution à votre solution. Dans Explorateur de solutions, dans le menu contextuel de votre solution, choisissez Ajouter>nouvel élément, puis sélectionnez fichier XML. Enregistrez le fichier avec un nom tel que test.runsettings.

Si vous ne voyez pas tous les modèles d’élément, choisissez Afficher tous les modèles, puis choisissez le modèle d’élément.

Conseil

Le nom de fichier n’a pas d’importance, tant que vous utilisez l’extension .runsettings.
Ajoutez le contenu de exemple de fichier *.runsettings, puis personnalisez-le en fonction de vos besoins, comme décrit dans les sections suivantes.
Spécifiez le fichier *.runsettings que vous souhaitez en utilisant l'une des méthodes suivantes :
- IDE Visual Studio
- Ligne de commande
- Générer un flux de travail à l’aide d’Azure Test Plans ou d’Azure DevOps Server (anciennement Team Foundation Server (TFS)).
Exécutez les tests unitaires pour utiliser les paramètres d’exécution personnalisés.

Si vous souhaitez désactiver et activer les paramètres personnalisés dans l’IDE, désélectionnez ou sélectionnez le fichier dans le menu Test.

Conseil

Vous pouvez créer plusieurs fichiers .runsettings dans votre solution et en sélectionner un en tant que fichier de paramètres de test actif en fonction des besoins.

Spécifier un fichier de paramètres d’exécution dans l’IDE

Les méthodes disponibles dépendent de votre version de Visual Studio.

Visual Studio 2019 version 16.4 et ultérieure

Il existe trois façons de spécifier un fichier de paramètres d’exécution dans Visual Studio 2019 version 16.4 et ultérieures.

détecter automatiquement les paramètres d’exécution
définir manuellement les paramètres d’exécution
Définir une propriété de build

Détection automatique du fichier de paramètres d’exécution

Remarque

Cela fonctionne uniquement pour un fichier nommé .runsettings.

Pour détecter automatiquement le fichier de paramètres d’exécution, placez-le à la racine de votre solution.

Si la détection automatique des fichiers de paramètres d’exécution est activée, les paramètres de ce fichier sont appliqués à toutes les exécutions de tests. Vous pouvez activer la détection automatique des fichiers runsettings à l’aide de deux méthodes :

Sélectionnez Outils>Options>Test>Détection automatique des fichiers runsettings
Sélectionnez Tester>Configurer les paramètres d’exécution>Détecter automatiquement les fichiers runsettings

Sélectionner manuellement le fichier de paramètres d’exécution

Dans l’IDE, sélectionnez Tester>Configurer les paramètres d’exécution>Sélectionner le fichier runsettings à l’échelle de la solution, puis sélectionnez le fichier .runsettings.

Ce fichier remplace le fichier .runsettings à la racine de la solution, le cas échéant, et est appliqué à toutes les exécutions de tests.
Cette sélection de fichiers persiste uniquement localement.

Sélectionner le menu de fichier runsettings à l’échelle de la solution de test dans Visual Studio

Définissez une propriété de build

Ajoutez une propriété de build à un projet via le fichier projet ou un fichier Directory.Build.props. Le fichier de paramètres d’exécution d’un projet est spécifié par la propriété RunSettingsFilePath.

Les paramètres d’exécution au niveau du projet sont actuellement pris en charge dans les projets C#, VB, C++et F#.
Un fichier spécifié pour un projet remplace tout autre fichier de paramètres d’exécution spécifié dans la solution.
Ces propriétés MSBuild peuvent être utilisées pour spécifier le chemin d’accès au fichier runsettings.

Exemple de spécification d’un fichier .runsettings pour un projet :

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

Visual Studio 2019 version 16.3 et antérieure

Pour spécifier un fichier de paramètres d’exécution dans l’IDE, sélectionnez Test>Sélectionner un fichier de paramètres. Accédez au fichier .runsettings et sélectionnez-le.

Sélectionner le menu fichier de paramètres de test dans Visual Studio 2019

Le fichier apparaît dans le menu Test et vous pouvez le sélectionner ou le désélectionner. Quand il est sélectionné, le fichier de paramètres d’exécution s’applique quand vous sélectionnez Analyser la couverture du code.

Spécifier un fichier de paramètres d’exécution à partir de la ligne de commande

Pour exécuter des tests à partir de la ligne de commande, utilisez vstest.console.exeet spécifiez le fichier de paramètres à l’aide du paramètre /Settings.

Ouvrez Invite de commandes développeur pour Visual Studio.

Entrez une commande similaire à :

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

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

Pour plus d’informations, consultez Options de ligne de commande VSTest.Console.exe.

Fichier *.runsettings

Le fichier *.runsettings est un fichier XML qui contient différents éléments de configuration dans l’élément RunSettings. Sections qui suivent détaillent les différents éléments. Pour obtenir un exemple complet, consultez exemple de fichier *.runsettings.

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

Chacun des éléments de configuration est facultatif, car il a une valeur par défaut.

Élément RunConfiguration

<RunConfiguration>
    <MaxCpuCount>1</MaxCpuCount>
    <ResultsDirectory>.\TestResults</ResultsDirectory>
    <TargetPlatform>x86</TargetPlatform>
    <TargetFrameworkVersion>net6.0</TargetFrameworkVersion>
    <TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
    <TestCaseFilter>(TestCategory != Integration) &amp; (TestCategory != UnfinishedFeature)</TestCaseFilter>
    <TestSessionTimeout>10000</TestSessionTimeout>
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>

L’élément RunConfiguration peut inclure les éléments suivants :

Nœud	Par défaut	Valeurs
MaxCpuCount	1	Le nom de l’option respecte le contrat et peut facilement être mal orthographié en tant que MaxCPUCount. Ce paramètre contrôle le niveau de parallélisme au niveau du processus. Utilisez 0 pour activer le parallélisme maximal au niveau du processus. Ce paramètre détermine le nombre maximal de DLL de test ou d’autres conteneurs de test qui peuvent s’exécuter en parallèle. Chaque DLL s'exécute dans son propre processus testhost et est isolée des tests des autres DLL de test au niveau du processus. Ce paramètre ne force pas les tests dans chaque DLL de test à s’exécuter en parallèle. Le contrôle de l’exécution parallèle au sein d’une DLL (au niveau du thread) est à la hauteur de l’infrastructure de test telle que MSTest, XUnit ou NUnit. La valeur par défaut est `1`, ce qui signifie qu’un seul testhost s’exécute en même temps. Une valeur spéciale `0` permet autant de testhosts que vous avez des processeurs logiques (par exemple, 6, pour un ordinateur avec 6 cœurs physiques sans multithreading, ou 12, pour un ordinateur avec six cœurs physiques avec multithreading). Le nombre de DLL distinctes dans l’exécution détermine le nombre réel de testhosts démarrés.
ResultsDirectory		Répertoire dans lequel les résultats des tests sont placés. Le chemin d’accès est relatif au répertoire qui contient le fichier .runsettings.
TargetFrameworkVersion	net40 ou netcoreapp1.0	Écarter toute cette balise pour détecter automatiquement. Ce paramètre définit la version du framework ou la famille d’infrastructure à utiliser pour exécuter des tests. Les valeurs acceptées sont n’importe quel moniker de framework tel que `net48`, `net472`,`net6.0`, `net5.0`, `netcoreapp3.1`, `uap10.0` ou tout nom de framework complet valide tel que`.NETFramework,Version=v4.7.2` ou `.NETCoreApp,Version=v6.0.0`. Pour la compatibilité descendante `Framework35`, `Framework40`, `Framework45`, `FrameworkCore10`, `FrameworkUap10` sont acceptés, ce qui signifie (`net35`, `net40`, `net45`, `netcoreapp1.0` et `uap10.0` respectivement). Toutes les valeurs ne respectent pas le contrat. La valeur fournie est utilisée pour déterminer le fournisseur d’exécution de test à utiliser. Chaque fournisseur de runtime de test doit respecter la famille d’infrastructure à utiliser, mais peut ne pas respecter la version exacte de l’infrastructure : Pour .NET Framework 4.5.1 - 4.8, un testhost généré avec la version exacte spécifiée est utilisé. Pour les valeurs en dehors de cette plage, .NET Framework 4.5.1 testhost est utilisé. Pour .NET, le `<TargetFramework>` du projet de test (ou plus précisément `runtimeconfig.json`) détermine la version réelle. Pour UWP, l’application de projet de test est un testhost par lui-même et détermine la version réelle de UWP utilisée. Omettez l’élément `TargetFrameworkVersion` du fichier .runsettings pour déterminer automatiquement la version du framework à partir des fichiers binaires générés. Lors de la détection automatique, toutes les infrastructures cibles sont unifiées dans un seul framework commun. Lorsqu’une version différente de la même famille de framework cible est trouvée, la version la plus récente est choisie (par exemple, net452, net472, net48 = net48). Pour l’exécuteur .NET Framework (dans Visual Studio ou vstest.console.exe dans la ligne de commande Développeur), l’infrastructure cible commune est net40. Pour l'environnement d'exécution .NET (dotnet test + DLLs), le framework cible commun est défini sur netcoreapp1.0.
TargetPlatform	x86	Omettez cette balise entière pour détecter automatiquement. Ce paramètre définit l’architecture à utiliser pour exécuter des tests. Les valeurs possibles sont `x86`, `x64`, `ARM`, `ARM64`, `S390x`. Lors de la détection automatique, l’architecture des DLL AnyCPU peut différer en fonction de l’exécuteur. Pour l’exécuteur .NET Framework (dans Visual Studio ou vstest.console.exe dans la ligne de commande Développeur), la valeur par défaut est x86. Pour l’exécuteur .NET (test dotnet), la valeur par défaut est l’architecture de processus actuelle.
TreatTestAdapterErrorsAsWarnings	faux	faux, vrai
TestAdaptersPaths		Un ou plusieurs chemins d’accès au répertoire où se trouvent les TestAdapters
TestCaseFilter		Expression de filtre au format <propriété><opérateur><valeur>[\|&<Expression>]. L’opérateur booléen & doit être représenté par l’entité HTML & ;. Les expressions peuvent être placées entre parenthèses. Pour obtenir une syntaxe détaillée sur la structure d’expressions, consultez vstest/docs/filter.md.
TempsD’ExpirationDeLaSessionDeTest		Permet aux utilisateurs d’arrêter une session de test lorsqu’elle dépasse un délai d’expiration donné, spécifié en millisecondes. La définition d’un délai d’attente garantit que les ressources sont bien consommées et que les sessions de test sont limitées à une heure définie. Le paramètre est disponible dans Visual Studio 2017 version 15.5 et versions ultérieures.
DotnetHostPath		Spécifiez un chemin d’accès personnalisé à l’hôte dotnet utilisé pour exécuter le testhost. Il est utile lorsque vous créez votre propre dotnet, par exemple lors de la création du dépôt dotnet/runtime. La spécification de cette option ignore la recherche de testhost.exeet force l’utilisation de testhost.dll.
TreatNoTestsAsError	faux	vrai ou faux Spécifiez une valeur booléenne, qui définit le code de sortie lorsqu’aucun test n’est découvert. Si la valeur est `true` et qu’aucun test n’est détecté, un code de sortie différent de zéro est retourné. Sinon, zéro est retourné.

Élément DataCollectors (adaptateurs de données de diagnostic)

L’élément DataCollectors spécifie les paramètres des adaptateurs de données de diagnostic. Les adaptateurs de données de diagnostic recueillent des informations supplémentaires sur l’environnement et l’application en cours de test. Chaque adaptateur a des paramètres par défaut et vous devez uniquement fournir des paramètres si vous ne souhaitez pas utiliser les paramètres par défaut.

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

Collecteur de données CodeCoverage

Le collecteur de données de couverture du code crée un rapport des parties du code d'application qui ont été exercées dans le test. Pour plus d’informations sur la personnalisation des paramètres de couverture du code, consultez Personnaliser l’analyse de couverture du code.

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

Collecteur de données VideoRecorder

Le collecteur de données vidéo capture un enregistrement d’écran lors de l’exécution des tests. Cet enregistrement est utile pour résoudre les problèmes liés aux tests de l’interface utilisateur. Le collecteur de données vidéo est disponible dans Visual Studio 2017 version 15.5 et versions ultérieures. Pour obtenir un exemple de configuration de ce collecteur de données, consultez l’exemple de fichier *.runsettings .

Pour personnaliser tout autre type d’adaptateurs de données de diagnostic, utilisez un fichier de paramètres de test .

Blâmer le collecteur de données

Cette option peut vous aider à isoler un test problématique qui provoque un crash de l'hôte de test. L’exécution du collecteur crée un fichier de sortie (Sequence.xml) dans TestResults, qui capture l’ordre d’exécution du test avant le crash.

Vous pouvez exécuter les responsabilités dans trois modes différents :

Mode fichier séquence : pour créer un fichier avec la liste des tests jusqu’au blocage
Mode vidage sur incident : pour créer une image mémoire lorsque testhost se bloque
Mode vidage sur blocage : pour créer une image mémoire lorsque le test ne se termine pas avant le délai d’expiration donné

La configuration XML doit être placée directement dans <RunSettings> nœud :

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

Les paramètres d’exécution de test permettent de définir des variables et des valeurs disponibles pour les tests au moment de l’exécution. Accédez aux paramètres à l’aide de la propriété MSTest TestContext.Properties (ou du NUnit TestContext) :

public TestContext TestContext { get; set; }

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

Pour utiliser des paramètres d’exécution de test, ajoutez une propriété de TestContext publique à votre classe de test.

Élément LoggerRunSettings

La section LoggerRunSettings définit un ou plusieurs enregistreurs d’événements à utiliser pour l’exécution de test. Les enregistreurs d’événements les plus courants sont la console, le fichier de résultats des tests Visual Studio (trx) et 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>

Élément MSTest

Ces paramètres sont spécifiques à l’adaptateur de test qui exécute les méthodes de test qui ont l’attribut TestMethodAttribute.

<MSTest>
    <MapInconclusiveToFailed>True</MapInconclusiveToFailed>
    <CaptureTraceOutput>false</CaptureTraceOutput>
    <DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
    <DeploymentEnabled>False</DeploymentEnabled>
    <ConsiderFixturesAsSpecialTests>False</ConsiderFixturesAsSpecialTests>
    <AssemblyResolution>
      <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
    </AssemblyResolution>
</MSTest>

Configuration	Par défaut	Valeurs
ForcedLegacyMode	faux	Dans les versions antérieures de Visual Studio, l’adaptateur MSTest a été optimisé pour le rendre plus rapide et plus évolutif. Certains comportements, tels que l’ordre dans lequel les tests sont exécutés, peuvent ne pas être exactement comme dans les éditions précédentes de Visual Studio. Définissez la valeur sur true pour utiliser l’ancien adaptateur de test. Par exemple, vous pouvez utiliser ce paramètre si vous avez un fichier app.config spécifié pour un test unitaire. Nous vous recommandons de refactoriser vos tests pour vous permettre d’utiliser l’adaptateur plus récent.
SettingsFile		Vous pouvez spécifier un fichier de paramètres de test à utiliser avec l’adaptateur MSTest ici. Vous pouvez également spécifier un fichier de paramètres de test à partir du menu paramètres. Si vous spécifiez cette valeur, vous devez également affecter à ForcedLegacyMode la valeur true. `<ForcedLegacyMode>true</ForcedLegacyMode>`
DeploymentEnabled	vrai	Si vous définissez la valeur sur false, les éléments de déploiement que vous avez spécifiés dans votre méthode de test ne sont pas copiés dans le répertoire de déploiement.
CaptureTraceOutput	vrai	Capturez des messages texte provenant de `Console.Write`, `Trace.Write`, `Debug.Write*` API qui seront associés au test en cours d’exécution.
EnableBaseClassTestMethodsFromOtherAssemblies	vrai	Valeur indiquant s’il faut activer la découverte de méthodes de test à partir de classes de base dans un assembly différent de la classe de test héritée.
ClassCleanupLifecycle	EndOfClass	Si vous souhaitez que le nettoyage de la classe se produise à la fin de l'assemblage, définissez-le sur EndOfAssembly. (Non pris en charge à partir de MSTest v4, car EndOfClass est le comportement par défaut et unique de ClassCleanup)
MapNotRunnableToFailed	vrai	Valeur indiquant si un résultat non exécutable est mappé au test ayant échoué.
Paralléliser	Utilisé pour définir les paramètres de parallélisation : Workers: Le nombre de fils de traitement/travailleurs à utiliser pour la parallélisation, qui est par défaut le nombre de processeurs sur l’ordinateur actuel. SCOPE: étendue de la parallélisation. Vous pouvez la définir sur MethodLevel. Par défaut, il s’agit ClassLevel. `<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>`
TestTimeout	0	Obtient le délai d’expiration du cas de test global spécifié.
TraiterLesAvertissementsDeDécouverteCommeDesErreurs	faux	Pour signaler des avertissements de découverte de tests en tant qu’erreurs, définissez cette valeur sur true.
TreatClassAndAssemblyCleanupWarningsAsErrors	faux	Pour voir vos échecs des nettoyages de classe sous forme d’erreurs, affectez à cette valeur la valeur true.
DeployTestSourceDependencies	vrai	Valeur indiquant si les références sources de test doivent être déployées.
DeleteDeploymentDirectoryAfterTestRunIsComplete	vrai	Pour conserver le répertoire de déploiement après une exécution de test, définissez cette valeur sur false.
MapInconclusiveToFailed	faux	Si un test se termine avec un état Non concluant, il est mappé à l’état Ignoré dans l’Explorateur de tests. Si vous souhaitez que les tests inconclusifs soient affichés comme ayant échoué, définissez la valeur sur true.
ConsiderFixturesAsSpecialTests	faux	Pour afficher `AssemblyInitialize`, `AssemblyCleanup`, `ClassInitialize`, `ClassCleanup` en tant qu’entrées individuelles dans Visual Studio et Visual Studio Code `Test Explorer` et journal `.trx`, définissez cette valeur sur true
RésolutionDeL'Assemblée	faux	Vous pouvez spécifier des chemins d’accès à des assemblies supplémentaires lors de la recherche et de l’exécution de tests unitaires. Par exemple, utilisez ces chemins d’accès pour les assemblys de dépendance qui ne se trouvent pas dans le même répertoire que l’assembly de test. Pour spécifier un chemin, utilisez un élément Directory Path. Les chemins d’accès peuvent inclure des variables d’environnement. `<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>` Notez que cette fonctionnalité est appliquée uniquement lors de l’utilisation de la cible .NET Framework.

Exemple de fichier .runsettings

Le code XML suivant montre le contenu d’un fichier .runsettings standard. Copiez ce code et modifiez-le en fonction de vos besoins.

Chaque élément du fichier est facultatif, car il a une valeur par défaut.

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

Spécifier des variables d’environnement dans le fichier .runsettings

Les variables d’environnement peuvent être définies dans le fichier .runsettings, qui peut interagir directement avec l’hôte de test. La spécification de variables d’environnement dans le fichier .runsettings est nécessaire pour prendre en charge les projets nontrivial qui nécessitent la définition de variables d’environnement comme DOTNET_ROOT. Ces variables sont définies lors de la génération du processus hôte de test et sont disponibles dans l’hôte.

Exemple

Le code suivant est un exemple fichier .runsettings qui transmet des variables d’environnement :

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

Le nœud RunConfiguration doit contenir un nœud EnvironmentVariables. Une variable d’environnement peut être spécifiée en tant que nom d’élément et sa valeur.

Remarque

Étant donné que ces variables d’environnement doivent toujours être définies lorsque l’hôte de test est démarré, les tests doivent toujours s’exécuter dans un processus distinct. Pour cela, l’indicateur /InIsolation sera défini lorsqu’il existe des variables d’environnement afin que l’hôte de test soit toujours appelé.

Partage via

Configurer des tests unitaires à l’aide d’un fichier .runsettings

Créer un fichier de paramètres d’exécution et le personnaliser

Spécifier un fichier de paramètres d’exécution dans l’IDE

Visual Studio 2019 version 16.4 et ultérieure

Détection automatique du fichier de paramètres d’exécution

Sélectionner manuellement le fichier de paramètres d’exécution

Définissez une propriété de build

Visual Studio 2019 version 16.3 et antérieure

Spécifier un fichier de paramètres d’exécution à partir de la ligne de commande

Fichier *.runsettings

Élément RunConfiguration

Élément DataCollectors (adaptateurs de données de diagnostic)

Collecteur de données CodeCoverage

Collecteur de données VideoRecorder

Blâmer le collecteur de données

TestRunParameters

Élément LoggerRunSettings

Élément MSTest

Exemple de fichier .runsettings

Spécifier des variables d’environnement dans le fichier .runsettings

Exemple

Commentaires

Ressources supplémentaires

Partage via

Configurer des tests unitaires à l’aide d’un fichier .runsettings

Créer un fichier de paramètres d’exécution et le personnaliser

Spécifier un fichier de paramètres d’exécution dans l’IDE

Visual Studio 2019 version 16.4 et ultérieure

Détection automatique du fichier de paramètres d’exécution

Sélectionner manuellement le fichier de paramètres d’exécution

Définissez une propriété de build

Visual Studio 2019 version 16.3 et antérieure

Spécifier un fichier de paramètres d’exécution à partir de la ligne de commande

Fichier *.runsettings

Élément RunConfiguration

Élément DataCollectors (adaptateurs de données de diagnostic)

Collecteur de données CodeCoverage

Collecteur de données VideoRecorder

Blâmer le collecteur de données

TestRunParameters

Élément LoggerRunSettings

Élément MSTest

Exemple de fichier .runsettings

Spécifier des variables d’environnement dans le fichier .runsettings

Exemple

Contenu connexe

Commentaires

Ressources supplémentaires