Configurer des tests unitaires à l’aide d’un fichier .runsettings
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.
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.
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.
Entrez une commande semblable à la suivante :
vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettingsou
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) & (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>
<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. |
| 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) & (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é.
Contenu connexe
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour