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

Article
09/11/2024

Un fichier .runsettings peut être utilisé pour configurer la façon dont les tests unitaires sont exécutés. Par exemple, vous pouvez l’utiliser pour changer la version de .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 série de tests. Une utilisation courante d’un fichier .runsettings est de personnaliser l’analyse de la couverture du code.

Les fichiers de paramètres d’exécution permettent de configurer des tests qui sont exécutés depuis la ligne de commande, dans l’IDE ou dans un flux de travail de build avec Azure Test Plans ou Azure DevOps Server (anciennement appelé Team Foundation Server (TFS)).

Les fichiers de paramètres d’exécution sont facultatifs. Si vous n’avez pas besoin d’une configuration spéciale, un fichier .runsettings n’est pas nécessaire.

Créez un fichier de paramètres d’exécution et personnalisez-le

Ajoutez un fichier de paramètres d’exécution à votre solution. Dans l’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 du fichier n’a pas d’importance, à condition d’utiliser l’extension .runsettings.
Ajoutez le contenu de l’exemple *.runsettings,puis personnalisez-le en fonction de vos besoins, comme décrit dans les sections suivantes.
Spécifiez le fichier *.runsettings souhaité à l’aide de l’une des méthodes suivantes :
- IDE Visual Studio
- Ligne de commande
- Créez un workflow à l’aide d’Azure Test Plans ou d’Azure DevOps Server (anciennement appelé 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 16.4 et versions ultérieures

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érieure.

Détection automatique des 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

Notes

Cela fonctionnera 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électionnez 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é à tous les tests exécutés.
Cette sélection de fichier est conservée 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érieures

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

Option de menu Sélectionner le fichier de paramètres des tests 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écifiez un fichier de paramètres d’exécution à partir de la ligne de commande

Pour exécuter des tests depuis la ligne de commande, utilisez vstest.console.exe et 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 semblable à la suivante :

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.

Le fichier *.runsettings

Le fichier *.runsettings est un fichier XML qui contient différents éléments de configuration au sein de l’élément RunSettings. Les 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	Default	Valeurs
MaxCpuCount	1	Le nom de l’option respecte la casse 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 au niveau du processus des tests dans d’autres DLL de test. Ce paramètre ne force pas les tests de 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) dépend 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 à la fois. 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 où 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	Omettre cette balise entière pour la détection automatique. Ce paramètre définit la version de l’infrastructure ou la famille d’infrastructure à utiliser pour exécuter des tests. Les valeurs acceptées sont n’importe quel moniker d’infrastructure tel que `net48`, `net472`,`net6.0`, `net5.0`, `netcoreapp3.1`, `uap10.0` ou tout nom d’infrastructure 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`, `net45netcoreapp1.0` et `uap10.0` respectivement). Toutes les valeurs ne respectent pas la casse. La valeur fournie est utilisée pour déterminer le fournisseur de runtime 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 serveur de test qui a été 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, la version réelle est déterminée par le projet de test `<TargetFramework>` (ou plus précisément `runtimeconfig.json`). Pour UWP, l’application de projet de test est un testhost en soi et détermine la version réelle d’UWP utilisée. Omettez l’élément `TargetFrameworkVersion` du fichier .runsettings pour déterminer automatiquement la version de l’infrastructure à partir des fichiers binaires générés. Lors de la détection automatique, toutes les infrastructures cibles sont unifiées dans une infrastructure commune unique. Lorsqu’une version différente de la même famille de l’infrastructure 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’exécuteur .NET (test dotnet + DLL), l’infrastructure cible commune est définie sur netcoreapp1.0.
TargetPlatform	x86	Omettre cette balise entière pour la détection automatique. 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	false	false, true
TestAdaptersPaths		Un ou plusieurs chemins du 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’expression, consultez vstest/docs/filter.md.
TestSessionTimeout		Permet aux utilisateurs de mettre fin à une session de test lorsque celle-ci dépasse le délai spécifié. La définition d’un délai d’expiration garantit que les ressources sont consommées et que les sessions de test sont limitées à une durée spécifique. Le paramètre est disponible dans Visual Studio 2017 versions 15.5 et ultérieures.
DotnetHostPath		Spécifiez un chemin d’accès personnalisé à l’hôte dotnet utilisé pour exécuter l’hôte testhost. Cela est utile lorsque vous générez votre propre dotnet, par exemple lors de la création du référentiel dotnet/runtime. La spécification de cette option ignore la recherche de testhost.exe et force l’utilisation de testhost.dll.
TreatNoTestsAsError	false	true ou false Spécifiez une valeur booléenne, qui définit le code de sortie lorsqu’aucun test n’est détecté. Si la valeur est `true` et qu’aucun test n’est détecté, un code de sortie autre que zéro est retourné. Sinon, la valeur zéro est renvoyée.

É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 rassemblent des informations supplémentaires sur l’environnement et sur l’application testée. Chaque adaptateur a des paramètres par défaut. Il vous suffit de fournir des paramètres si vous ne souhaitez pas utiliser les valeurs 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 journal des parties du code d’application qui ont été testées. Pour plus d’informations sur la personnalisation des paramètres pour la couverture du code, consultez Personnaliser l’analyse de la 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 de l’écran quand des tests sont exécutés. Cet enregistrement est utile pour résoudre les problèmes des tests d’interface utilisateur. Le collecteur de données vidéo est disponible dans Visual Studio 2017 versions 15.5 et ultérieures. Pour obtenir un exemple de configuration de ce collecteur de données, consultez Exemple de fichier *.runsettings.

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

Collecteur de données de responsabilité

Cette option peut vous aider à isoler un test problématique qui provoque un plantage 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 plantage.

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 le nœud <RunSettings> :

<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 de série de tests fournissent un moyen de définir des variables et des valeurs qui sont 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 de NUnit TestContext) :

private string _appUrl;
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 publique TestContext à 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 disposant de 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	Default	Valeurs
ForcedLegacyMode	false	Dans les anciennes versions de Visual Studio, l’adaptateur MSTest a été optimisé afin d’être plus rapide et plus scalable. Un comportement, tel que l’ordre dans lequel les tests sont exécutés, peut ne pas être exactement identique à celui d’éditions précédentes de Visual Studio. Définissez la valeur sur true pour utiliser l’adaptateur de test le plus ancien. Par exemple, vous pouvez utiliser ce paramètre si un fichier app.config est spécifié pour un test unitaire. Il est recommandé d’envisager de refactoriser vos tests pour vous permettre d’utiliser le nouvel adaptateur.
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 de paramètres. Si vous spécifiez cette valeur, vous devez également affecter à ForcedLegacyMode la valeur true. `<ForcedLegacyMode>true</ForcedLegacyMode>`
DeploymentEnabled	true	Si vous définissez cette 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	true	Capturez les messages textuels provenant de l'api `Console.Write`, `Trace.Write`, `Debug.Write*` qui seront associés au test en cours d'exécution.
EnableBaseClassTestMethodsFromOtherAssemblies	true	Valeur indiquant s’il est nécessaire d’activer la découverte des méthodes de test à partir de classes de base dans un autre assembly que celui de la classe de test qui hérite.
ClassCleanupLifecycle	EndOfClass	Si vous souhaitez que le nettoyage de classe se produise à la fin de l’assembly, affectez la valeur EndOfAssembly. (N’est plus pris en charge à partir de MSTest v4, car EndOfClass est le seul comportement par défaut de ClassCleanup)
MapNotRunnableToFailed	true	Valeur indiquant si un résultat non exécutable est mappé à un test non réussi.
Parallelize	Utilisé pour définir les paramètres de parallélisation : Workers : nombre de threads/workers à utiliser pour la parallélisation, qui correspond par défaut au nombre de processeurs de la machine actuelle. SCOPE : étendue de la parallélisation. Vous pouvez lui affecter la valeur MethodLevel. Par défaut, ClassLevel est utilisé. `<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>`
TestTimeout	0	Obtient le délai d’expiration du cas de test global spécifié.
TreatDiscoveryWarningsAsErrors	false	Pour signaler des avertissements de découverte de tests en tant qu’erreurs, définissez cette valeur sur true.
TreatClassAndAssemblyCleanupWarningsAsErrors	false	Pour voir vos échecs des nettoyages de classe sous forme d’erreurs, affectez à cette valeur la valeur true.
DeployTestSourceDependencies	true	Valeur indiquant si les références de source de test doivent être déployées.
DeleteDeploymentDirectoryAfterTestRunIsComplete	true	Pour conserver le répertoire de déploiement après une série de tests, définissez cette valeur sur false.
MapInconclusiveToFailed	false	Si un test se termine avec un état Non concluant, il est mappé à l’état Ignoré dans l’Explorateur de tests. Si vous voulez que les tests non concluants s’affichent comme ayant échoué, définissez la valeur sur true.
ConsiderFixturesAsSpecialTests	false	Pour afficher `AssemblyInitialize`, `AssemblyCleanup`, `ClassInitialize`, `ClassCleanup` en tant qu'entrées individuelles dans le journal de Visual Studio et Visual Studio Code `Test Explorer` et `.trx`, définissez cette valeur sur vrai.
AssemblyResolution	false	Vous pouvez spécifier des chemins d’assemblys supplémentaires pour la recherche et l’exécution des tests unitaires. Par exemple, utilisez ces chemins 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 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 illustre le contenu d’un fichier .runsettings type. Copiez ce code et modifiez-le selon 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écifiez 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 non dérivés qui nécessitent de définir des variables d’environnement telles que DOTNET_ROOT. Ces variables sont définies lors de la génération du processus hôte de test et elles sont disponibles dans l’hôte.

Exemple

Le code suivant est un exemple de 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.

Notes

É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é.

Partager via

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

Créez un fichier de paramètres d’exécution et personnalisez-le

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

Visual Studio 2019 16.4 et versions ultérieures

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

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

Définissez une propriété de build

Visual Studio 2019 version 16.3 et antérieures

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

Le fichier *.runsettings

Élément RunConfiguration

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

Collecteur de données CodeCoverage

Collecteur de données VideoRecorder

Collecteur de données de responsabilité

TestRunParameters

Élément LoggerRunSettings

Élément MSTest

Exemple de fichier .runsettings

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

Exemple

Commentaires

Ressources supplémentaires

Partager via

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

Créez un fichier de paramètres d’exécution et personnalisez-le

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

Visual Studio 2019 16.4 et versions ultérieures

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

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

Définissez une propriété de build

Visual Studio 2019 version 16.3 et antérieures

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

Le fichier *.runsettings

Élément RunConfiguration

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

Collecteur de données CodeCoverage

Collecteur de données VideoRecorder

Collecteur de données de responsabilité

TestRunParameters

Élément LoggerRunSettings

Élément MSTest

Exemple de fichier .runsettings

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

Exemple

Contenu connexe

Commentaires

Ressources supplémentaires