Compartir a través de


Configura pruebas unitarias mediante un archivo de .runsettings

Se puede usar un archivo .runsettings para configurar cómo se ejecutan las pruebas unitarias. Por ejemplo, se puede usar para cambiar la versión de .NET en la que se ejecutan las pruebas, el directorio de los resultados de la prueba o los datos recopilados durante una ejecución de prueba. Un uso común de un archivo .runsettings es para personalizar el análisis de cobertura de código.

Los archivos Runsettings se pueden usar para configurar pruebas que se ejecutan desde la línea de comandos , desde el IDE o en un flujo de trabajo de compilación mediante Azure Test Plans o Azure DevOps Server (anteriormente conocido como Team Foundation Server (TFS)).

Los archivos Runsettings son opcionales. Si no necesita ninguna configuración especial, no necesita un archivo de .runsettings.

Crear un archivo de configuración de ejecución y personalizarlo

  1. Agregue un archivo de configuración de ejecución a la solución. En Explorador de Soluciones, en el menú contextual de la solución, elija Agregar>Nuevo Elementoy seleccione Archivo XML. Guarde el archivo con un nombre como test.runsettings.

    Si no ve todas las plantillas de elemento, elija Mostrar todas las plantillasy, a continuación, elija la plantilla de elemento.

    Sugerencia

    El nombre de archivo no importa, siempre que use la extensión .runsettings.

  2. Agregue el contenido que se muestra en el archivo de ejemplo *.runsettings y, después, personalícelo de acuerdo con sus necesidades tal como se describe en las secciones siguientes.

  3. Especifique el archivo *.runsettings que desea usar mediante uno de los siguientes métodos:

  4. Ejecute las pruebas unitarias para usar la configuración de ejecución personalizada.

Si quiere desactivar y activar los parámetros personalizados en el IDE, anule la selección del archivo o selecciónelo en el menú Prueba.

Sugerencia

Puedes crear más de un archivo .runsettings en tu solución y seleccionar uno como archivo de configuración de prueba activo según sea necesario.

Especificar un archivo de configuración de ejecución en el IDE

Los métodos disponibles dependen de la versión de Visual Studio.

Visual Studio 2019, versión 16.4 y posteriores

Hay tres maneras de especificar un archivo de configuración de ejecución en Visual Studio 2019, versión 16.4 y posteriores.

Detección automática del archivo de configuración de ejecución

Nota

Esto solo funcionará para un archivo denominado .runsettings.

Para detectar automáticamente el archivo de configuración de ejecución, colóquelo en la raíz de la solución.

Si la detección automática de archivos de configuración de ejecución está habilitada, la configuración de este archivo se aplica en todas las pruebas ejecutadas. Puede activar la detección automática de archivos runsettings mediante dos métodos:

  • Seleccione Herramientas>Opciones>Prueba>Detectar archivos runsettings automáticamente

    Opción de detección automática de archivos runsettings en Visual Studio

  • Seleccione Prueba>Configurar parámetros de ejecución>Detectar archivos runsettings automáticamente

    Menú Detectar archivos runsettings automáticamente en Visual Studio

Selección manual del archivo de configuración de ejecución

En el IDE, seleccione Test>Configure Run Settings>Select Solution Wide runsettings File (Probar > Configurar parámetros de ejecución > Seleccionar archivo runsettings en toda la solución) y, después, seleccione el archivo .runsettings.

  • Este archivo invalida el .runsettings archivo en la raíz de la solución, si hay uno presente, y se aplica en todas las pruebas ejecutadas.
  • Esta selección de archivo solo se conserva localmente.

Menú Seleccionar archivos runsettings en toda la solución de prueba en Visual Studio

Establecimiento de una propiedad de compilación

Agregue una propiedad de compilación a un proyecto mediante el archivo de proyecto o un archivo Directory.Build.props. El archivo de configuración de ejecución de un proyecto se especifica mediante la propiedad RunSettingsFilePath.

  • La configuración de ejecución de nivel de proyecto se admite actualmente en proyectos de C#, VB, C++y F#.
  • Un archivo especificado para un proyecto invalida cualquier otro archivo de configuración de ejecución especificado en la solución.
  • estas propiedades de MSBuild se pueden usar para especificar la ruta de acceso al archivo runsettings.

Ejemplo de especificación de un archivo de .runsettings para un proyecto:

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

Visual Studio 2019, versión 16.3 y anteriores

Para especificar un archivo de parámetros de ejecución en el IDE, seleccione Prueba>Seleccionar archivo de configuración. Busque y seleccione el archivo .runsettings.

Seleccionar archivo de configuración de prueba en el menú de Visual Studio 2019

El archivo aparece en el menú Prueba y puede seleccionarlo o anular su selección. Mientras está seleccionado, el archivo de parámetros de ejecución se aplica siempre que seleccione Analizar cobertura de código.

Especificar un archivo de configuración de ejecución desde la línea de comandos

Para ejecutar pruebas desde la línea de comandos, use vstest.console.exey especifique el archivo de configuración mediante el parámetro /Settings.

  1. Abra Símbolo del sistema para desarrolladores de Visual Studio.

  2. Escriba un comando similar al siguiente:

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

    o

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

Para obtener más información, consulte VSTest.Console.exe opciones de línea de comandos.

El archivo *.runsettings

El archivo *.runsettings es un archivo XML que contiene diferentes elementos de configuración dentro del elemento RunSettings. Las secciones siguientes detallan los distintos elementos. Para obtener un ejemplo completo, vea Archivo de ejemplo *.runsettings.

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

Cada uno de los elementos de configuración es opcional porque tiene un valor predeterminado.

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

El elemento RunConfiguration puede incluir los siguientes elementos:

Nodo Predeterminado Valores
MaxCpuCount 1 La opción de nombre distingue mayúsculas y minúsculas, por lo que es fácil escribir mal el nombre como MaxCPUCount.

Esta configuración controla el nivel de paralelismo en el nivel de proceso. Use 0 para habilitar el paralelismo de nivel de proceso máximo.

Esta configuración determina el número máximo de archivos DLL de prueba u otros contenedores de prueba que se pueden ejecutar en paralelo. Cada archivo DLL se ejecuta en su propio proceso testhost y se aísla en el nivel de proceso de las pruebas de otros archivos DLL de prueba. Esta configuración no obliga a que las pruebas en cada DLL de prueba se ejecuten en paralelo. Controlar la ejecución en paralelo dentro de un archivo DLL (en el nivel de subproceso) depende del marco de pruebas, como MSTest, XUnit o NUnit.

El valor predeterminado es 1, lo que significa que solo se ejecuta un testhost al mismo tiempo. Un valor especial 0 permite tantos testhosts como tenga procesadores lógicos (por ejemplo, 6, para un equipo con 6 núcleos físicos sin multiproceso o 12, para un equipo con seis núcleos físicos con varios subprocesos).

El número de DLLs distintas en la ejecución determina el número real de testhosts iniciados.
ResultsDirectory Directorio donde se colocan los resultados de las pruebas. La ruta de acceso es relativa al directorio que contiene el archivo .runsettings.
TargetFrameworkVersion net40 o netcoreapp1.0 Omita esta etiqueta completa para la detección automática.

Esta configuración define la versión del marco o la familia de marcos que se van a usar para ejecutar pruebas.

Los valores aceptados son cualquier moniker de marco, como net48, net472,net6.0, net5.0, netcoreapp3.1, uap10.0 o cualquier nombre de marco completo válido, como.NETFramework,Version=v4.7.2 o .NETCoreApp,Version=v6.0.0. Para la compatibilidad con versiones anteriores Framework35, Framework40, Framework45, FrameworkCore10, FrameworkUap10 se aceptan, lo que significa (net35, net40, net45, netcoreapp1.0 y uap10.0 respectivamente). Todos los valores distinguen entre mayúsculas y minúsculas.

El valor proporcionado se usa para determinar el proveedor de tiempo de ejecución de prueba que se va a usar. Todos los proveedores de tiempo de ejecución de prueba deben respetar la familia de marcos que se va a usar, pero es posible que no respeten la versión exacta del marco:

Para .NET Framework 4.5.1 - 4.8, se usa un testhost que se creó con la versión exacta especificada. Para los valores fuera de ese intervalo, se usa testhost de .NET Framework 4.5.1.

Para .NET, el <TargetFramework> del proyecto de prueba (o más precisamente runtimeconfig.json) determina la versión real.

Para UWP, la aplicación del proyecto de prueba es un anfitrión de prueba en sí misma y determina la versión efectiva de UWP que se usa.

Omita el elemento TargetFrameworkVersion del archivo de .runsettings para determinar automáticamente la versión del marco de trabajo de los archivos binarios compilados.

Al detectar automáticamente, todas las plataformas de destino se unifican en un único marco común. Cuando se encuentra una versión diferente de la misma familia de marcos de destino, se elige la versión más reciente (por ejemplo, net452, net472, net48 = net48).

Para el ejecutor de .NET Framework (en Visual Studio o vstest.console.exe en la línea de comandos del desarrollador), el framework de destino común es net40. Para el ejecutor de .NET (prueba de dotnet + archivos DLL), la plataforma de destino común se establece en netcoreapp1.0.
TargetPlatform x86 Omita toda esta etiqueta para detectar automáticamente.

Esta configuración define la arquitectura que se va a usar para ejecutar pruebas. Los valores posibles son x86, x64, ARM, ARM64, S390x.

Al detectar automáticamente, la arquitectura de los archivos DLL de AnyCPU puede diferir en función del ejecutor. Para el ejecutor de .NET Framework (en Visual Studio o vstest.console.exe en la línea de comandos developer), el valor predeterminado es x86. Para el ejecutor de .NET (prueba de dotnet), el valor predeterminado es la arquitectura de proceso actual.

TratarErroresDelAdaptadorDePruebaComoAdvertencias falso false, true
TestAdaptersPaths Una o varias rutas de acceso al directorio donde se encuentran los TestAdapters
TestCaseFilter Una expresión de filtro en el formato <propiedad><operador><valor>[|&<Expresión>]. El operador booleano & debe representarse mediante la entidad HTML &. Las expresiones se pueden incluir entre paréntesis. Para obtener una sintaxis detallada sobre la estructura de expresiones, consulte vstest/docs/filter.md.
TestSessionTimeout Permite a los usuarios finalizar una sesión de prueba cuando supera un tiempo de espera determinado, especificado en milisegundos. Establecer un tiempo de espera garantiza que los recursos se consuman correctamente y que las sesiones de prueba estén restringidas a un tiempo establecido. La configuración está disponible en visual Studio 2017, versión 15.5, y versiones posteriores.
DotnetHostPath Especifique una ruta de acceso personalizada al host dotnet que se usa para ejecutar el testhost. Resulta útil al compilar un dotnet propio, por ejemplo, al compilar el repositorio dotnet/runtime. Al especificar esta opción, se omite la búsqueda de testhost.exey se fuerza el uso de testhost.dll.
TreatNoTestsAsError falso verdadero o falso
Especifique un valor booleano, que define el código de salida cuando no se detecta ninguna prueba. Si el valor es true y no se detecta ninguna prueba, se devuelve un código de salida distinto de cero. De lo contrario, se devuelve cero.

Elemento de Colección de Datos (adaptadores de datos de diagnóstico)

El elemento DataCollectors especifica la configuración de los adaptadores de datos de diagnóstico. Los adaptadores de datos de diagnóstico recopilan información adicional sobre el entorno y la aplicación en prueba. Cada adaptador tiene la configuración predeterminada y solo tiene que proporcionar la configuración si no quiere usar los valores predeterminados.

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

Recopilador de datos codeCoverage

El recopilador de datos de cobertura del código crea un registro de qué partes del código de la aplicación han sido utilizadas en la prueba. Para obtener información detallada sobre cómo personalizar la configuración de cobertura de código, consulte Personalizar el análisis de cobertura de código.

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

Recopilador de datos de VideoRecorder

El recopilador de datos de vídeo captura una grabación de pantalla cuando se ejecutan pruebas. Esta grabación es útil para solucionar problemas de pruebas de interfaz de usuario. El recopilador de datos de vídeo está disponible en visual Studio 2017 versión 15.5 y versiones posteriores. Para obtener un ejemplo de configuración de este recopilador de datos, vea el ejemplo de archivo *.runsettings.

Para personalizar cualquier otro tipo de adaptadores de datos de diagnóstico, use un archivo de configuración de prueba .

Recopilador de datos de Blame

Esta opción puede ayudarle a aislar una prueba problemática que hace que el host de prueba se bloquee. Al ejecutar el recopilador, se crea un archivo de salida (Sequence.xml) en TestResults, donde se captura el orden de ejecución de la prueba antes del bloqueo.

Puede ejecutar el comando "blame" en tres modos diferentes:

  • Modo de archivo de secuencia: para crear un archivo con la lista de pruebas hasta el bloqueo
  • Modo de volcado de memoria: para crear un volcado de memoria cuando testhost se bloquea
  • Modo de volcado de bloqueo: para crear un volcado cuando la prueba no finalice antes de un tiempo de espera determinado

La configuración XML debe colocarse directamente en <RunSettings> nodo:

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

ParámetrosDePrueba

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

Los parámetros de ejecución de pruebas proporcionan una manera de definir variables y valores que están disponibles para las pruebas en tiempo de ejecución. Acceda a los parámetros mediante la propiedad MSTest TestContext.Properties (o la propiedad TestContext de NUnit):

public TestContext TestContext { get; set; }

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

Para usar parámetros de ejecución de pruebas, agregue una propiedad de TestContext pública a la clase de prueba.

Elemento LoggerRunSettings

La sección LoggerRunSettings define uno o varios registradores que se usarán para la ejecución de pruebas. Los registradores más comunes son la consola, el archivo de resultados de pruebas de Visual Studio (trx) y 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>

Elemento MSTest

Esta configuración es específica del adaptador de prueba que ejecuta métodos de prueba que tienen el atributo 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>
Configuración Predeterminado Valores
ForcedLegacyMode falso En versiones anteriores de Visual Studio, el adaptador de MSTest se ha optimizado para que sea más rápido y escalable. Es posible que algún comportamiento, como el orden en el que se ejecutan las pruebas, no sea exactamente igual que en ediciones anteriores de Visual Studio. Establezca el valor en true para usar el adaptador de prueba anterior.

Por ejemplo, puede usar esta configuración si tiene un archivo app.config especificado para una prueba unitaria.

Se recomienda considerar la posibilidad de refactorizar las pruebas para que pueda usar el adaptador más reciente.
SettingsFile Puede especificar un archivo de configuración de prueba que se usará con el adaptador de MSTest aquí. También puede especificar un archivo de configuración de prueba en el menú de configuración.

Si especifica este valor, también debe establecer ForcedLegacyMode en true.

<ForcedLegacyMode>true</ForcedLegacyMode>
DeploymentEnabled true Si establece el valor en false, los elementos de implementación especificados en el método de prueba no se copian en el directorio de implementación.
CaptureTraceOutput true Capture mensajes de texto procedentes de la API Console.Write*, Trace.Write*, Debug.Write* que se asociarán a la prueba en ejecución actual.
EnableBaseClassTestMethodsFromOtherAssemblies true Valor que indica si se va a habilitar la detección de métodos de prueba de clases base en un ensamblado diferente de la clase de prueba heredada.
ClassCleanupLifecycle EndOfClass Si desea que la limpieza de clases se realice al final de la compilación, establézcala en EndOfAssembly. (Ya no se admite a partir de MSTest v4, ya que EndOfClass es el comportamiento de limpieza de clase predeterminado, aparte del único)
MapNotRunnableToFailed true Valor que indica si un resultado no ejecutable se asigna a una prueba fallida.
Parallelize Se usa para establecer la configuración de paralelización:

Workers: número de subprocesos o trabajos que se usarán para la paralelización, que es de forma predeterminada el número de procesadores de la máquina actual.

ÁMBITO: Ámbito de paralelización. Puede establecerlo en MethodLevel. De forma predeterminada, es ClassLevel.

<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>
TestTimeout 0 Obtiene el tiempo de espera del caso de prueba global especificado.
TreatDiscoveryWarningsAsErrors falso Para notificar advertencias de detección de pruebas como errores, establezca este valor en true.
TreatClassAndAssemblyCleanupWarningsAsErrors falso Para ver los problemas en las limpiezas de clases como errores, establezca este valor en true.
DeployTestSourceDependencies true Valor que indica si se van a implementar las referencias de origen de prueba.
DeleteDeploymentDirectoryAfterTestRunIsComplete true Para conservar el directorio de implementación después de una ejecución de prueba, establezca este valor en false.
MapInconclusiveToFailed falso Si una prueba finaliza un estado no concluyente, se le asigna el estado Omitido en el Explorador de pruebas. Si desea que las pruebas no conclusivas se muestren como erróneas, establezca el valor en true.
ConsiderFixturesAsSpecialTests falso Para mostrar AssemblyInitialize, AssemblyCleanup, ClassInitialize, ClassCleanup como entradas individuales en Visual Studio y Visual Studio Code Test Explorer y en el registro de .trx, establezca este valor en verdadero
AssemblyResolution falso Puede especificar rutas de acceso a ensamblados adicionales al buscar y ejecutar pruebas unitarias. Por ejemplo, use estas rutas de acceso para los ensamblados de dependencia que no están en el mismo directorio que el ensamblado de prueba. Para especificar una ruta de acceso, use un elemento Directory Path. Las rutas de acceso pueden incluir variables de entorno.

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

Tenga en cuenta que esta característica solo se aplica al usar el destino de .NET Framework.

Archivo de ejemplo .runsettings

El siguiente XML muestra el contenido de un archivo .runsettings típico. Copie este código y edítelo para satisfacer sus necesidades.

Cada elemento del archivo es opcional porque tiene un valor predeterminado.

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

Especificar variables de entorno en el archivo de .runsettings

Las variables de entorno se pueden establecer en el archivo .runsettings, que puede interactuar directamente con el host de prueba. Es necesario especificar variables de entorno en el archivo .runsettings para admitir proyectos notriviales que requieren establecer variables de entorno como DOTNET_ROOT. Estas variables se establecen al generar el proceso de host de prueba y están disponibles en el host.

Ejemplo

El código siguiente es un ejemplo archivo .runsettings que pasa variables de entorno:

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

El nodo RunConfiguration debe contener un nodo EnvironmentVariables. Se puede especificar una variable de entorno como un nombre de elemento y su valor.

Nota

Dado que estas variables de entorno siempre deben establecerse cuando se inicia el host de prueba, las pruebas siempre se deben ejecutar en un proceso independiente. Para ello, se establecerá la marca /InIsolation cuando haya variables de entorno para que siempre se invoque el host de prueba.