Configuración de pruebas unitarias con un archivo .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 las pruebas o los datos recopilados durante una serie de pruebas. Un uso común de un archivo .runsettings es para personalizar el análisis de cobertura de código.
Los archivos de parámetros de ejecución se pueden usar para configurar pruebas que se ejecuten desde la línea de comandos, el IDE o 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 es necesaria una configuración especial, no se necesita un archivo .runsettings.
Creación y personalización de un archivo de parámetros de ejecución
Agregue un archivo de parámetros de ejecución a la solución. En el Explorador de soluciones, en el menú contextual de la solución, seleccione Agregar>Nuevo elemento y seleccione Archivo XML. Guarde el archivo con un nombre como test.runsettings.
Si no ve todas las plantillas de elemento, seleccione Mostrar todas las plantillas y elija la plantilla de elemento.
Sugerencia
El nombre de archivo no importa, siempre que use la extensión .runsettings.
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.
Especifique el archivo *.runsettings que quiera mediante uno de los métodos siguientes:
- IDE de Visual Studio
- Línea de comandos
- Cree un flujo de trabajo mediante Azure Test Plans o Azure DevOps Server (anteriormente conocido como Team Foundation Server [TFS]).
Ejecute las pruebas unitarias para usar los parámetros de ejecución personalizados.
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
Puede crear más de un archivo .runsettings en la solución y seleccionar uno como archivo de configuración de pruebas activo según sea necesario.
Especificar un archivo de parámetros de ejecución en el IDE
Los métodos disponibles dependerán de la versión de Visual Studio.
Visual Studio 2019, versión 16.4 y posteriores
Hay tres formas de especificar un archivo de parámetros de ejecución en la versión 16.4 de Visual Studio 2019 y posteriores.
- Detección automática de los parámetros de ejecución
- Establecimiento manual de los parámetros de ejecución
- Establecimiento de una propiedad de compilación
Detección automática del archivo de parámetros de ejecución
Nota
Esto solo funcionará para un archivo denominado .runsettings.
Para detectar automáticamente el archivo de parámetros de ejecución, colóquelo en la raíz de la solución.
Si está habilitada la detección automática de archivos de parámetros de ejecución, la configuración de este archivo se aplica a todas las pruebas ejecutadas. Puede activar la detección automática de los archivos runsettings siguiendo uno de estos dos métodos:
Seleccione Herramientas>Opciones>Prueba>Detectar archivos runsettings automáticamente
Seleccione Prueba>Configurar parámetros de ejecución>Detectar archivos runsettings automáticamente
Selección manual del archivo de parámetros 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 reemplaza .runsettings en la raíz de la solución, si hay alguno, y se aplica a todas las pruebas ejecutadas.
- Esta selección del archivo solo se conserva localmente.
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 parámetros de ejecución de un proyecto se especifica mediante la propiedad RunSettingsFilePath.
- Los parámetros de ejecución de nivel de proyecto se admiten actualmente en proyectos C#, VB, C++ y F#.
- Un archivo especificado para un proyecto invalida cualquier otro archivo de parámetros 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 cómo especificar un archivo .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.
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.
Especificación de un archivo de parámetros de ejecución desde la línea de comandos
Para ejecutar pruebas desde la línea de comandos, utilice vstest.console.exe y especifique el archivo de configuración mediante el parámetro /Settings.
Abra Símbolo del sistema para desarrolladores de Visual Studio.
Escriba un comando similar a:
vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettingso
vstest.console.exe --settings:test.runsettings test.dll
Para obtener más información, vea Opciones de la línea de comandos para VSTest.Console.exe.
Archivo *.runsettings
El archivo *.runsettings es un archivo XML que contiene distintos elementos de configuración dentro del elemento RunSettings. En las secciones siguientes se 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 elemento de configuración es opcional porque tiene su 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) & (TestCategory != UnfinishedFeature)</TestCaseFilter>
<TestSessionTimeout>10000</TestSessionTimeout>
<TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>
El elemento RunConfiguration puede incluir los siguientes elementos:
| Nodo | Default | 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 máximo de nivel de proceso. 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 aisla en el nivel de proceso de las pruebas de otros archivos DLL de prueba. Esta configuración no obliga a que las pruebas de cada archivo DLL de prueba se ejecuten en paralelo. El control de 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 de forma simultánea. El valor especial 0 permite tantos testhosts como procesadores lógicos (por ejemplo, 6 para un equipo con seis núcleos físicos sin multiproceso o 12 para un equipo con seis núcleos físicos con varios subprocesos).El número de archivos DLL distintos de la ejecución determina el número real de testhosts iniciados. |
| ResultsDirectory | Directorio en el que 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 del marco que se va a usar para ejecutar pruebas. Los valores aceptados son cualquier moniker de marco, como net48, net472, net6.0, net5.0, netcoreapp3.1 o 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 se aceptan Framework35, Framework40, Framework45, FrameworkCore10 y FrameworkUap10, 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 entorno de ejecución de prueba que se va a usar. Todos los proveedores de entornos de ejecución de pruebas 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 el testhost de .NET Framework 4.5.1. Para .NET, el valor <TargetFramework> del proyecto de prueba (o más concretamente runtimeconfig.json) determina la versión actual.Para UWP, la aplicación de proyecto de prueba es un testhost por sí misma y determina la versión real de UWP que se usa. Omita el elemento TargetFrameworkVersion del archivo .runsettings para determinar automáticamente la versión del marco a partir de los archivos binarios compilados.Al realizar la detección automática, todos los marcos de destino se unifican en un único marco común. Cuando se encuentra una versión diferente de la misma familia de plataformas 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 para desarrolladores), el marco 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 esta etiqueta completa para la detección automática. Esta configuración define la arquitectura que se va a usar para ejecutar pruebas. Los valores posibles son x86, x64, ARM, ARM64 y S390x.Al realizar la detección automática, 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 para desarrolladores), el valor predeterminado es x86. Para el ejecutor de .NET (prueba de dotnet), el valor predeterminado es la arquitectura de proceso actual. |
| TreatTestAdapterErrorsAsWarnings | False | 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 pueden incluirse entre paréntesis. Para obtener una sintaxis detallada sobre la estructura de expresiones, consulte vstest/docs/filter.md. | |
| TestSessionTimeout | Permite a los usuarios terminar una sesión de prueba cuando esta supera un tiempo de espera especificado. La configuración de un tiempo de espera garantiza que los recursos se utilicen de manera conveniente y que las sesiones de prueba se limiten a un tiempo establecido. Esta opción está disponible en Visual Studio 2017, versión 15.5 y posteriores. | |
| DotnetHostPath | Especifique una ruta de acceso personalizada al host dotnet que se usa para ejecutar 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.exe y se fuerza el uso de testhost.dll. | |
| TreatNoTestsAsError | false | 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 DataCollectors (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 pruebas. Cada adaptador tiene una configuración predeterminada, por lo que solo tiene que proporcionar valores si no quiere usar los predeterminados.
<DataCollectionRunSettings>
<DataCollectors>
<!-- data collectors -->
</DataCollectors>
</DataCollectionRunSettings>
Recopilador de datos CodeCoverage
El recopilador de datos de cobertura de código crea un registro de las partes del código de aplicación que se han empleado en las pruebas. Para obtener información detallada sobre la personalización de los valores de cobertura de código, vea 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 VideoRecorder
El recopilador de datos de vídeo captura una grabación de pantalla cuando se ejecutan las 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 posteriores. Para obtener un ejemplo de la configuración de este recopilador de datos, vea Archivo de ejemplo *.runsettings.
Para personalizar cualquier otro tipo de adaptador de datos de diagnóstico, use un archivo de configuración de pruebas.
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 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 el nodo <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>
Los parámetros de la serie de pruebas proporcionan una manera de definir las variables y los valores que están disponibles para las pruebas en tiempo de ejecución. Acceda a los parámetros mediante la propiedad TestContext.Properties de MSTest (o TestContext de NUnit):
private string _appUrl;
public TestContext TestContext { get; set; }
[TestMethod] // [Test] for NUnit
public void HomePageTest()
{
string _appUrl = TestContext.Properties["webAppUrl"];
}
Para usar parámetros de serie de pruebas, agregue una propiedad TestContext pública a la clase de prueba.
Elemento LoggerRunSettings
En la sección LoggerRunSettings se definen uno o varios registradores 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
Estos valores son específicos del adaptador de pruebas que ejecuta métodos de prueba con el atributo TestMethodAttribute .
<MSTest>
<MapInconclusiveToFailed>True</MapInconclusiveToFailed>
<CaptureTraceOutput>false</CaptureTraceOutput>
<DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
<DeploymentEnabled>False</DeploymentEnabled>
<AssemblyResolution>
<Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
</AssemblyResolution>
</MSTest>
| Configuración | Default | Valores |
|---|---|---|
| ForcedLegacyMode | false | En versiones anteriores de Visual Studio, el adaptador MSTest se optimizó para que fuera más rápido y escalable. Es posible que parte del comportamiento, como el orden en que se ejecutan las pruebas, no sea exactamente igual que en ediciones anteriores de Visual Studio. Establezca este valor en true para utilizar el adaptador de pruebas más antiguo. Por ejemplo, es posible usar este valor si tiene un archivo app.config especificado para una prueba unitaria. Se recomienda que considere la refactorización de las pruebas para poder usar el adaptador más reciente. |
| SettingsFile | Puede especificar un archivo de configuración de pruebas para usarlo con el adaptador MSTest aquí. También puede especificarlo en el menú Configuración. Si especifica este valor, también debe establecer ForcedLegacyMode en true. <ForcedLegacyMode>true</ForcedLegacyMode> |
|
| DeploymentEnabled | true | Si el valor se establece en false, los elementos de implementación especificados en el método de prueba no se copian al 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 desde clases base en un ensamblado diferente desde la clase de prueba heredada. |
| ClassCleanupLifecycle | EndOfClass | Si quiere que la limpieza de clases se produzca al final del ensamblado, establezca este valor 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 se asignará a la prueba con errores un resultado no ejecutable. |
| 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. SCOPE: á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 | false | Para notificar advertencias de detección de pruebas como errores, establezca este valor en true. |
| TreatClassAndAssemblyCleanupWarningsAsErrors | false | 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 del origen de la prueba. |
| DeleteDeploymentDirectoryAfterTestRunIsComplete | true | Para conservar el directorio de implementación después de una serie de pruebas, establezca este valor en false. |
| MapInconclusiveToFailed | False | Si una prueba finaliza un estado no concluyente, se le asigna el estado Omitido en el Explorador de pruebas. Si quiere que las pruebas no concluyentes se muestren como Error, establezca el valor en true. |
| AssemblyResolution | False | Puede especificar rutas de acceso a más ensamblados cuando busque y ejecute pruebas unitarias. Por ejemplo, puede utilizar estas rutas de acceso para los ensamblados de dependencias que no estén en el mismo directorio que el ensamblado de pruebas. 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 el código y edítelo para satisfacer sus necesidades.
Cada elemento del archivo es opcional, porque cada valor 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) & (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>
Especificación de variables de entorno en el archivo .runsettings
Las variables de entorno se pueden establecer en el archivo .runsettings, que puede interactuar directamente con el host de prueba. Especificar variables de entorno en el archivo .runsettings es necesario para admitir proyectos no triviales que requieren configurar variables de entorno como, por ejemplo, DOTNET_ROOT. Estas variables se establecen al generar el proceso del host de prueba y están disponibles en el host.
Ejemplo
El siguiente código es un archivo .runsettings de ejemplo 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. Una variable de entorno se puede especificar como un nombre de elemento y su valor.
Nota
Dado que estas variables de entorno siempre deben estar establecidas cuando el host de prueba se inicia, las pruebas siempre deben ejecutarse en un proceso independiente. Para ello, se establecerá la marca /InIsolation cuando haya variables de entorno, para que el host de prueba siempre se invoque.
Contenido relacionado
- Configuración de una serie de pruebas
- Personalizar el análisis de cobertura de código
- Visual Studio test task (Azure Test Plans) [Tarea de prueba de Visual Studio (Azure Test Plans)]
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de