dotnet test

  • Artículo
  • 5 minutos para leer

Este artículo se aplica a: ✔️ SDK de .NET Core 2.1 y versiones posteriores

NOMBRE

dotnet test: controlador de prueba de .NET usado para ejecutar pruebas unitarias.

Sinopsis

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL>]
    [-a|--test-adapter-path <ADAPTER_PATH>] [--arch <ARCHITECTURE>]
    [--blame] [--blame-crash]
    [--blame-crash-dump-type <DUMP_TYPE>] [--blame-crash-collect-always]
    [--blame-hang] [--blame-hang-dump-type <DUMP_TYPE>]
    [--blame-hang-timeout <TIMESPAN>]
    [-c|--configuration <CONFIGURATION>]
    [--collect <DATA_COLLECTOR_NAME>]
    [-d|--diag <LOG_FILE>] [-f|--framework <FRAMEWORK>]
    [--filter <EXPRESSION>] [--interactive]
    [-l|--logger <LOGGER>] [--no-build]
    [--nologo] [--no-restore] [-o|--output <OUTPUT_DIRECTORY>] [--os <OS>]
    [-r|--results-directory <RESULTS_DIR>] [--runtime <RUNTIME_IDENTIFIER>]
    [-s|--settings <SETTINGS_FILE>] [-t|--list-tests]
    [-v|--verbosity <LEVEL>] [[--] <RunSettings arguments>]

dotnet test -h|--help

Descripción

El comando dotnet test se usa para ejecutar pruebas unitarias en una solución determinada. El comando dotnet test compila la solución y ejecuta una aplicación host de prueba para cada proyecto de prueba de la solución. El host de prueba ejecuta las pruebas en el proyecto especificado mediante un marco de pruebas (por ejemplo, MSTest, NUnit o xUnit) e informa del éxito o el error de cada prueba. Si todas las pruebas son correctas, el ejecutor de pruebas devuelve 0 como un código de salida; en caso contrario, si se produce algún error en una prueba, devuelve 1.

En el caso de los proyectos con varios destinos, las pruebas se ejecutan para cada plataforma de destino. El host de pruebas y el marco de pruebas unitarias se empaquetan como paquetes NuGet y se restauran como dependencias ordinarias para el proyecto.

Los proyectos de prueba especifican el ejecutor de pruebas usando un elemento <PackageReference> ordinario, como se puede ver en este archivo de proyecto de ejemplo:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.0.0" />
    <PackageReference Include="xunit" Version="2.4.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.3" />
  </ItemGroup>

</Project>

Donde Microsoft.NET.Test.Sdk es el host de prueba y xunit es el marco de pruebas. Y xunit.runner.visualstudio es un adaptador de prueba, que permite que el marco xUnit funcione con el host de prueba.

Restauración implícita

No es necesario ejecutar dotnet restore porque lo ejecutan implícitamente todos los comandos que necesitan que se produzca una restauración, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish y dotnet pack. Para deshabilitar la restauración implícita, use la opción --no-restore.

El comando dotnet restore sigue siendo válido en algunos escenarios donde tiene sentido realizar una restauración explícita, como las compilaciones de integración continua en Azure DevOps Services o en los sistemas de compilación que necesitan controlar explícitamente cuándo se produce la restauración.

Para obtener información sobre cómo administrar fuentes de NuGet, vea la documentación de dotnet restore.

Descargas de manifiestos de cargas de trabajo

Cuando se ejecuta, este comando inicia una descarga asincrónica en segundo plano de manifiestos de publicidad de cargas de trabajo. Si la descarga no ha terminado cuando finaliza el comando, se detiene. Para obtener más información, vea Manifiestos de publicidad.

Argumentos

  • PROJECT | SOLUTION | DIRECTORY | DLL

    • Ruta de acceso al proyecto de prueba.
    • Ruta de acceso a la solución.
    • Ruta de acceso a un directorio que contiene un proyecto o una solución.
    • Ruta de acceso a un archivo .dll del proyecto de prueba.

    Si no se especifica, se busca un proyecto o una solución en el directorio actual.

Opciones

  • -a|--test-adapter-path <ADAPTER_PATH>

    Ruta de acceso a un directorio en el que se van hacer búsquedas de adaptadores de prueba adicionales. Solo se inspeccionan los archivos .dll con el sufijo .TestAdapter.dll. Si no se especifica, la búsqueda se realiza en el directorio del archivo .dll de la prueba.

  • --arch <ARCHITECTURE>

    Especifica la arquitectura de destino. Se trata de una sintaxis abreviada para establecer el identificador del entorno de ejecución (RID), donde el valor proporcionado se combina con el RID predeterminado. Por ejemplo, en un equipo win-x64, al especificar --arch x86 se establece el RID en win-x86. Si usa esta opción, no use la opción -r|--runtime. Disponible a partir de .NET 6 (versión preliminar 7).

  • --blame

    Ejecuta las pruebas en el modo de culpabilidad. Esta opción es útil para aislar las pruebas problemáticas que hacen que el host de prueba se bloquee. Cuando se detecta un bloqueo, crea un archivo de secuencia en TestResults/<Guid>/<Guid>_Sequence.xml que captura el orden de las pruebas ejecutadas antes del bloqueo.

  • --blame-crash (Disponible a partir del SDK de .NET 5.0)

    Ejecuta las pruebas en modo de culpa y recopila un volcado de memoria cuando el host de prueba se cierra de forma inesperada. Esta opción depende de la versión de .NET que se use, del tipo de error y del sistema operativo.

    En el caso de las excepciones en el código administrado, se recopilará automáticamente un volcado de memoria en .NET 5.0 y versiones posteriores. Generará un volcado de memoria para el host de prueba o cualquier proceso secundario que también se haya ejecutado en .NET 5.0 y se haya bloqueado. Los bloqueos en código nativo no generarán volcado de memoria. Esta opción funciona en Windows, macOS y Linux.

    Los volcados de memoria en código nativo o cuando se usa .NET Core 3.1 o versiones anteriores solo se pueden recopilar en Windows, mediante Procdump. Un directorio que contenga procdump.exe y procdump64.exe debe estar en la variable de entorno PATH o PROCDUMP_PATH. Descargue las herramientas. Implica --blame.

    Para recopilar un volcado de memoria de una aplicación nativa que se ejecuta en .NET 5.0 o una versión posterior, se puede establecer la variable de entorno VSTEST_DUMP_FORCEPROCDUMP en 1 para forzar el uso de Procdump.

  • --blame-crash-dump-type <DUMP_TYPE> (Disponible a partir del SDK de .NET 5.0)

    El tipo de volcado de memoria que se va a recopilar. Implica --blame-crash.

  • --blame-crash-collect-always (Disponible a partir del SDK de .NET 5.0)

    Recopila un volcado de memoria en la salida de host de prueba esperada e inesperada.

  • --blame-hang (Disponible a partir del SDK de .NET 5.0)

    Ejecute las pruebas en modo de culpa y recopile un volcado de bloqueo cuando una prueba supere el tiempo de espera especificado.

  • --blame-hang-dump-type <DUMP_TYPE> (Disponible a partir del SDK de .NET 5.0)

    El tipo de volcado de memoria que se va a recopilar. Debe ser full, mini o none. Cuando se especifica none, el host de prueba finaliza en el tiempo de espera, pero no se recopila ningún volcado. Implica --blame-hang.

  • --blame-hang-timeout <TIMESPAN> (Disponible a partir del SDK de .NET 5.0)

    Tiempo de espera por prueba, después del cual se desencadena un volcado de bloqueo y se genera un volcado de memoria del proceso de host de prueba y todos sus procesos secundarios y se finalizan. El valor de tiempo de espera se especifica en uno de los siguientes formatos:

    • 1.5h, 1.5hour, 1.5hours
    • 90m, 90min, 90minute, 90minutes
    • 5400s, 5400sec, 5400second, 5400seconds
    • 5400000ms, 5400000mil, 5400000millisecond, 5400000milliseconds

    Cuando no se usa ninguna unidad (por ejemplo, 5 400 000), se supone que el valor está en milisegundos. Cuando se usa junto con las pruebas basadas en datos, el comportamiento de tiempo de espera depende del adaptador de prueba usado. En xUnit y NUnit, el tiempo de espera se renueva después de cada caso de prueba. En MSTest, el tiempo de espera se usa en todos los casos de prueba. Esta opción se admite en Windows con netcoreapp2.1 y versiones posteriores, en Linux con netcoreapp3.1 y versiones posteriores y en macOS con net5.0 o versiones posteriores. Implica --blame y --blame-hang.

  • -c|--configuration <CONFIGURATION>

    Define la configuración de compilación. El valor predeterminado para la mayoría de los proyectos es Debug, pero puede invalidar los valores de configuración de compilación en el proyecto.

  • --collect <DATA_COLLECTOR_NAME>

    Habilita el recopilador de datos para la ejecución de pruebas. Para obtener más información, consulte Monitor and analyze test run (Supervisar y analizar ejecuciones de pruebas).

    Para recopilar la cobertura de código en cualquier plataforma compatible con .NET Core, instale Coverlet y use la opción --collect:"XPlat Code Coverage".

    En Windows, puede recopilar la cobertura de código mediante la opción --collect "Code Coverage". Esta opción genera un archivo .coverage, que se puede abrir en Visual Studio 2019 Enterprise. Para más información, vea Uso de cobertura de código y Personalización del análisis de cobertura de código.

  • -d|--diag <LOG_FILE>

    Habilita el modo de diagnóstico de la plataforma de prueba y escribe mensajes de diagnóstico en el archivo especificado y en los archivos que hay junto a él. El proceso que registra los mensajes determina qué archivos se crean, como *.host_<date>.txt para el registro del host de prueba y *.datacollector_<date>.txt para el registro del recopilador de datos.

  • -f|--framework <FRAMEWORK>

    Fuerza el uso del host de prueba de dotnet o .NET Framework para los archivos binarios de prueba. Esta opción solo determina el tipo de host que se va a usar. La versión de Framework real que se va a usar viene determinada por runtimeConfig.json del proyecto de prueba. Si no se especifica, se usa el atributo de ensamblado TargetFramework para determinar el tipo de host. Si ese atributo se quita de .dll, se usa el host de .NET Framework.

  • --filter <EXPRESSION>

    Filtra las pruebas del proyecto actual con la expresión dada. Para más información, consulte la sección Detalles de la opción de filtro. Para obtener más información y ejemplos sobre cómo usar el filtrado de pruebas unitarias selectivas, vea Ejecución de pruebas unitarias selectivas.

  • -?|-h|--help

    Imprime una descripción de cómo usar el comando.

  • --interactive

    Permite que el comando se detenga y espere una entrada o una acción del usuario. Por ejemplo, para completar la autenticación. Disponible desde el SDK de .NET Core 3.0.

  • -l|--logger <LOGGER>

    Especifica un registrador para los resultados de pruebas. A diferencia de MSBuild, la prueba de dotnet no acepta abreviaturas: en lugar de -l "console;v=d" use -l "console;verbosity=detailed". Especifique el parámetro varias veces para habilitar varios registradores.

  • --no-build

    No compila el proyecto de prueba antes de ejecutarlo. También establece la marca - --no-restore de forma implícita.

  • --nologo

    Ejecuta pruebas sin mostrar la pancarta de Microsoft TestPlatform. Disponible desde el SDK de .NET Core 3.0.

  • --no-restore

    No ejecuta una restauración implícita al ejecutar el comando.

  • -o|--output <OUTPUT_DIRECTORY>

    Directorio donde se encuentran los archivos binarios que se ejecutarán. Si no se especifica la ruta de acceso predeterminada es ./bin/<configuration>/<framework>/. En el caso de los proyectos con varias plataformas de destino (a través de la propiedad TargetFrameworks), también debe definir --framework al especificar esta opción. dotnet test siempre ejecuta las pruebas desde el directorio de salida. Puede usar AppDomain.BaseDirectory para consumir recursos de prueba en el directorio de salida.

  • --os <OS>

    Especifica el sistema operativo (SO) de destino. Se trata de una sintaxis abreviada para establecer el identificador del entorno de ejecución (RID), donde el valor proporcionado se combina con el RID predeterminado. Por ejemplo, en un equipo win-x64, al especificar --os os se establece el RID en os-x64. Si usa esta opción, no use la opción -r|--runtime. Disponible a partir de .NET 6 (versión preliminar 7).

  • -r|--results-directory <RESULTS_DIR>

    El directorio donde se guardarán los resultados de pruebas. Si el directorio especificado no existe, se crea. El valor predeterminado es TestResults en el directorio que contiene el archivo del proyecto.

  • --runtime <RUNTIME_IDENTIFIER>

    Runtime de destino que probar.

  • -s|--settings <SETTINGS_FILE>

    El archivo .runsettings que se usará para ejecutar las pruebas. El elemento TargetPlatform (x86|x64) no tiene ningún efecto en dotnet test. Para ejecutar pruebas destinadas a x86, instale la versión x86 de .NET Core. El valor de bits de dotnet.exe que se encuentra en la ruta de acceso es lo que se usará para ejecutar las pruebas. Para obtener más información, vea los siguientes recursos:

  • -t|--list-tests

    Enumera las pruebas detectadas en vez de ejecutar las pruebas.

  • -v|--verbosity <LEVEL>

    Establece el nivel de detalle del comando. Los valores permitidos son q[uiet], m[inimal], n[ormal], d[etailed] y diag[nostic]. De manera predeterminada, es minimal. Para obtener más información, vea LoggerVerbosity.

  • Argumentos de RunSettings

Los argumentos RunSettings insertados se pasan como los últimos argumentos en la línea de comandos después de "-- " (fíjese en el espacio después de --). Los argumentos RunSettings insertados se especifican como pares de [name]=[value]. Se usa un espacio para separar varios pares de [name]=[value].

Ejemplo: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Para obtener más información, vea Paso de argumentos de RunSettings a través de la línea de comandos.

Ejemplos

  • Ejecución de las pruebas en el proyecto en el directorio actual:

    dotnet test

  • Ejecute las pruebas en el proyecto test1:

    dotnet test ~/projects/test1/test1.csproj

  • Ejecute las pruebas del proyecto en el directorio actual y genere un archivo de resultados de prueba en formato trx:

    dotnet test --logger trx

  • Ejecute las pruebas del proyecto en el directorio actual y genere un archivo de cobertura de código (después de instalar la integración de recopiladores de Coverlet):

    dotnet test --collect:"XPlat Code Coverage"

  • Ejecute las pruebas en el proyecto en el directorio actual y genere un archivo de cobertura de código (solo en Windows):

    dotnet test --collect "Code Coverage"

  • Ejecute las pruebas del proyecto en el directorio actual y regístrese con el nivel de detalle pormenorizado en la consola:

    dotnet test --logger "console;verbosity=detailed"

  • Ejecute las pruebas del proyecto en el directorio actual e informe de las pruebas que estaban en curso cuando se bloqueó el host de prueba:

    dotnet test --blame

Detalles de la opción de filtro

--filter <EXPRESSION>

<Expression> tiene el formato <property><operator><value>[|&<Expression>].

<property> es un atributo del tipo Test Case. Las siguientes son las propiedades admitidas por los marcos de pruebas unitarias populares:

Marco de prueba Propiedades admitidas
MSTest
  • FullyQualifiedName
  • NOMBRE
  • ClassName
  • Prioridad
  • TestCategory
xUnit
  • FullyQualifiedName
  • DisplayName
  • Category
NUnit
  • FullyQualifiedName
  • NOMBRE
  • TestCategory
  • Prioridad

<operator> describe la relación entre la propiedad y el valor:

Operador Función
= Coincidencia exacta
!= Coincidencia no exacta
~ Contiene
!~ No contiene

<value> es una cadena. Todas las búsquedas distinguen mayúsculas de minúsculas.

Una expresión sin <operator> automáticamente se considera un contains en la propiedad FullyQualifiedName (por ejemplo, dotnet test --filter xyz es lo mismo que dotnet test --filter FullyQualifiedName~xyz).

Las expresiones se pueden combinar con operadores condicionales:

Operador Función
| O
& AND

Si usa operadores condicionales (por ejemplo, (Name~TestMethod1) | (Name~TestMethod2)), puede incluir las expresiones entre paréntesis.

Para obtener más información y ejemplos sobre cómo usar el filtrado de pruebas unitarias selectivas, vea Ejecución de pruebas unitarias selectivas.

Vea también