prueba dotnet con Microsoft.Testing.Platform (MTP)

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

Nombre

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

Sinopsis

dotnet test
    [<PROJECT_OR_TRAVERSAL_PATH>]
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>]
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [--config-file <CONFIG_FILE>]
    [--results-directory <RESULTS_DIRECTORY>]
    [--results-directory-layout <flat|per-module>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <NUMBER>]
    [--maximum-failed-tests <NUMBER>]
    [--timeout <DURATION>]
    [-e|--environment <NAME="VALUE">]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--use-current-runtime|--ucr]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-dependencies]
    [--no-restore]
    [--nologo|--no-logo|--no-banner]
    [--no-ansi]
    [--no-progress]
    [--no-artifact-post-processing]
    [--output <VERBOSITY_LEVEL>]
    [--show-test-results <OUTCOME>]
    [--list-tests [text|json]]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [--device <DEVICE_ID>]
    [--list-devices]
    [--collect-test-map]
    [--affected-tests]
    [<args>...]

dotnet test -h|--help

Description

Con MTP, dotnet test funciona más rápido que con VSTest. Los argumentos relacionados con las pruebas ya no se fijan, ya que están vinculados a las extensiones registradas en los project de prueba. Además, MTP admite un filtro de globbing al ejecutar pruebas. Para obtener más información, consulte MTP.

Importante

Las opciones específicas de la extensión no están integradas en MTP. Cada aplicación de prueba de destino debe registrar la extensión que proporciona una opción. Agregue directamente el paquete NuGet de la extensión o use una configuración o perfil de SDK de prueba que incluya el paquete. De lo contrario, se produce un error en la ejecución de pruebas con el código de salida 5 porque no se reconoce la opción. Ejecute dotnet test --help para ver las opciones disponibles para las aplicaciones de prueba seleccionadas y vea Opciones de extensión por escenario para buscar el paquete para una opción.

Advertencia

Cuando MTP se opte por medio global.jsonde , dotnet test espera que todos los proyectos de prueba usen MTP. Se trata de un error si alguno de los proyectos de prueba usa VSTest.

Requisitos de versión

El modo MTP de dotnet test requiere el SDK de .NET 10 y MTP 1.7 o posterior. Las opciones agregadas después de .NET 10 tienen requisitos de versión de SDK individuales en las secciones siguientes. Algunas opciones también requieren un paquete MTP más reciente porque el SDK coordina la ejecución completa mientras cada aplicación de prueba implementa la funcionalidad correspondiente.

Restauración implícita

No es necesario ejecutar dotnet restore porque se ejecuta implícitamente por todos los comandos que requieren que se produzca una restauración, tales 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 útil en determinados escenarios en los que la restauración explícita tiene sentido, como compilaciones de integracióncontinuosas en Azure DevOps Services o en 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, consulte la documentación de dotnet restore.

Options

Nota:

Solo puede usar una de las siguientes opciones a la vez: --project, --solution o --test-modules. Estas opciones no se pueden combinar. Además, cuando se usa --test-modules, no se puede especificar --arch, --configuration, --framework--list-devices--device, --os, o . --runtime--use-current-runtime Estas opciones requieren evaluación del proyecto o no son relevantes para un módulo ya compilado.

  • PROJECT_OR_TRAVERSAL_PATH

    Especifica un proyecto o un proyecto de recorrido que se va a ejecutar. A partir de .NET 11 Preview 7, dotnet test admite Microsoft.Build.Traversal proyectos, como dirs.proj, y ejecuta de forma recursiva sus proyectos de prueba a los que se hace referencia.

    A partir de .NET 12 Preview 1, el argumento también puede identificar una aplicación de prueba mtP basada en archivos de C#. Las aplicaciones de prueba basadas en archivos no admiten --device.

  • --project <PROJECT_PATH>

    Especifica la ruta de acceso del archivo project que se va a ejecutar (nombre de carpeta o ruta de acceso completa). Si no se especifica, se toma como predeterminado el directorio actual.

  • --solution <SOLUTION_PATH>

    Especifica la ruta de acceso del archivo de solución que se va a ejecutar (nombre de carpeta o ruta de acceso completa). Si no se especifica, se toma como predeterminado el directorio actual.

  • --test-modules <EXPRESSION>

    Filtra los módulos de prueba mediante la globbing de archivos. Solo se ejecutan las pruebas que pertenecen a esos módulos de prueba. A partir de .NET 11 Preview 6, prefijo un patrón con ! para excluir módulos coincidentes. Separar varios patrones con punto y coma; Se omite el espacio en blanco alrededor de cada patrón.

  • --root-directory <ROOT_PATH>

    Especifica el directorio raíz de la opción --test-modules. Solo se puede usar con la opción --test-modules.

  • --max-parallel-test-modules <NUMBER>

    Especifica el número máximo de módulos de prueba que se pueden ejecutar en paralelo. El valor predeterminado es Environment.ProcessorCount.

  • --config-file <CONFIG_FILE>

    Especifica el archivo de configuración que se va a usar para la ejecución de pruebas. Si se proporciona una ruta de acceso relativa, se convierte en una ruta de acceso absoluta basada en el directorio actual. Para obtener más información sobre los valores del archivo de configuración, vea testconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

    Especifica el directorio donde se almacenan los resultados de las pruebas. Si el directorio no existe, se crea. Si se proporciona una ruta de acceso relativa, se convierte en una ruta de acceso absoluta basada en el directorio actual.

  • --results-directory-layout <flat|per-module>

    Especifica cómo una ejecución de varios módulos organiza los archivos en el directorio de resultados. El valor predeterminado, flat, escribe todos los resultados en el mismo directorio. per-module escribe los resultados de cada módulo en <project>/<target-framework>_<runtime-or-architecture>, lo que impide que los informes con el mismo nombre de archivo sobrescriban entre sí.

    Disponible a partir de .NET 11 RC 1.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

    Especifica el directorio donde se almacena la salida de diagnóstico. Si el directorio no existe, se crea. Si se proporciona una ruta de acceso relativa, se convierte en una ruta de acceso absoluta basada en el directorio actual.

  • --minimum-expected-tests <NUMBER>

    Especifica un número mínimo positivo de pruebas para toda la ejecución. Si el recuento de pruebas agregadas es menor que el mínimo especificado, se produce un error en la ejecución de pruebas con el código de salida 9. El recuento global incluye pruebas omitidas. Para obtener más información sobre los códigos de salida, consulte Códigos de salida de MTP.

    Dado que esta opción aparece antes --de , es una opción global (ejecución completa). Para requerir un mínimo para cada módulo de prueba en su lugar, pase la opción después -- para que se reenvíe a todos los módulos de prueba. Para obtener más información, consulte Los mínimos de ejecución completa y por módulo.

    Nota:

    El mínimo global requiere el SDK de .NET 10 (10.0.100) o una versión posterior.

  • --maximum-failed-tests <NUMBER>

    Detiene la ejecución completa después de alcanzar el número especificado de pruebas con errores, con errores, agotados o cancelados. La ejecución se cierra con el código 13.

    Disponible a partir de .NET 11 Preview 7 y requiere MTP 2.4 o posterior.

  • --timeout <DURATION>

    Detiene la ejecución completa después de la duración especificada mientras se ejecuta al menos una aplicación de prueba. Especifique un número positivo seguido de una unidad, como 500ms, 90s, 10m, 2ho 1d. Una ejecución con tiempo de espera se cierra con el código 3.

    Disponible a partir de .NET 11 Preview 7 y requiere MTP 2.4 o posterior.

  • -e|--environment <NAME="VALUE">

    Establece una variable de entorno para el proceso de prueba. Especifique la opción varias veces para establecer varias variables. Los valores de la línea de comandos invalidan los valores de un perfil de inicio.

    Use .NET SDK 10.0.110 o posterior cuando no exista ningún perfil de inicio o cuando especifique --no-launch-profile; las versiones anteriores del SDK de .NET 10 pueden omitir las variables en esos casos. A partir de .NET 11 Preview 7, las variables también fluyen a destinos de compilación, implementación e implementación compatibles con funcionalidades.

  • -a|--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 desde .NET 6 Preview 7.

  • --artifacts-path <ARTIFACTS_DIR>

    Todos los archivos de salida de compilación del comando ejecutado se incluirán en subcarpetas en la ruta de acceso especificada, separadas por el proyecto. Para obtener más información, vea diseño de salida de artefactos . Esta opción y el valor proporcionado deben estar explícitamente en cascada en cualquier dotnet comando que dependa de la salida de otro dotnet comando, por ejemplo, al usar dotnet build --no-restore y dotnet publish --no-build. Disponible desde .NET 8 SDK.

    Disponible para el modo MTP a partir de .NET 11.

  • -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 las opciones de configuración de compilación en el project.

  • -f|--framework <FRAMEWORK>

    Moniker de la plataforma de destino (TFM) del marco de destino para el que ejecutarán pruebas La plataforma de destino también debe especificarse en el archivo project.

  • --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 linux se establece el RID en linux-x64. Si usa esta opción, no use la opción -r|--runtime. Disponible desde .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Runtime de destino que probar.

    Formato corto -r disponible a partir de .NET SDK 7.

    Nota:

    No se admite la ejecución de pruebas para una solución con una propiedad global RuntimeIdentifier (explícitamente o a través --archde , --runtimeo --os). Establezca RuntimeIdentifier en un nivel de project individual en su lugar.

  • --use-current-runtime|--ucr

    Usa el tiempo de ejecución actual como tiempo de ejecución de destino durante la restauración y la compilación.

    Disponible a partir de .NET 11 Preview 6. No se puede combinar esta opción con --test-modules.

  • -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]. Para obtener más información, consulte LoggerVerbosity.

  • --no-build

    Especifica que el project de prueba no se compila antes de ejecutarse. También establece implícitamente la marca --no-restore.

  • --no-dependencies

    Omite la compilación de referencias de proyecto a proyecto.

    Disponible a partir de .NET 11 Preview 6.

  • --no-restore

    Especifica que no se ejecuta una restauración implícita al ejecutar el comando .

  • --nologo|--no-logo|--no-banner

    Suprime los banners de inicio de .NET y MTP. También se admiten los -nologo formularios y /nologo y la variable de DOTNET_NOLOGO entorno.

    Disponible en el modo MTP a partir de .NET 11 Preview 7.

  • --no-ansi

    Deshabilita la salida de caracteres de escape ANSI para la pantalla.

  • --no-progress

    Deshabilita el progreso de los informes en pantalla.

  • --no-artifact-post-processing

    Deshabilita el posprocesamiento de artefactos compatibles después de ejecutar un módulo múltiple. A partir de .NET 11 RC 1 y MTP 2.4, los postprocesadores de artefacto registrados pueden combinar informes compatibles, como los resultados de TRX. Si se produce un error en el procesamiento posterior, el SDK conserva los artefactos originales y el código de salida de prueba.

  • --output <VERBOSITY_LEVEL>

    Especifica el nivel de detalle de salida para los resultados de la prueba. Los valores válidos son Minimal, Normaly Detailed. El valor predeterminado es Normal. Minimal requiere la versión preliminar de MTP 2.4.

  • --show-test-results <OUTCOME>

    Selecciona bloques de resultados por resultado. En la versión preliminar de MTP 2.4, use passed, failed, skipped, allo none. El failed valor también incluye errores, tiempos de espera y cancelaciones.

    Combine passed, failedy skipped con comas, espacios o opciones repetidas --show-test-results . No combine all ni none con otro valor. Esta opción explícita invalida el --output valor preestablecido independientemente del orden de las opciones.

  • --list-tests [text|json]

    Enumera las pruebas detectadas sin ejecutarlas. Omita el valor o especifique text para la salida legible. A partir de .NET 11 Preview 7, especifique json para un documento JSON con versiones que agrupa las pruebas por ensamblado, marco de destino y arquitectura e incluye identificadores disponibles, ubicaciones de origen, métodos, parámetros y rasgos.

  • --no-launch-profile

    No intente usar launchSettings.json para configurar la aplicación. De forma predeterminada, launchSettings.json se usa , que puede aplicar variables de entorno y argumentos de línea de comandos al ejecutable de prueba.

  • --no-launch-profile-arguments

    No use argumentos especificados por commandLineArgs en el perfil de inicio para ejecutar la aplicación.

  • --device <DEVICE_ID>

    Selecciona un dispositivo, emulador o simulador para cada plataforma de destino en un proyecto de prueba de Android o iOS. La ruta mtP también admite proyectos de prueba macOS y Mac Catalyst. Si la entrada es interactiva y hay más de un dispositivo disponible, dotnet test puede solicitarle que seleccione uno.

    Disponible a partir de .NET 11 Preview 6. En el caso de los proyectos de varios destinos, use .NET 11 RC 2 o posterior para que la detección de dispositivos evalúe correctamente cada plataforma de destino. Esta opción no admite proyectos de prueba de WebAssembly del explorador.

  • --list-devices

    Enumera los dispositivos disponibles para un proyecto sin ejecutar pruebas. Especifique un proyecto en lugar de una solución.

    Disponible a partir de .NET 11 Preview 7.

  • --collect-test-map y --affected-tests

    Recopile un mapa de prueba del repositorio o ejecute pruebas afectadas por un cambio. Estas opciones experimentales requieren una extensión distribuida por separado y la variable de DOTNET_CLI_ENABLE_AFFECTED_TESTS=1 entorno. No se pueden combinar las dos opciones. Los flujos de trabajo de prueba afectados tampoco admiten pruebas de dispositivos, módulos de pruebas en paralelo ni directivas de prueba mínima.

    Disponible a partir de .NET 11 RC 1.

  • --property:<NAME>=<VALUE>

    Establece una o varias propiedades MSBuild. Especifique varias propiedades repitiendo la opción:

    --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

    La forma abreviada -p se puede usar para --property. Lo mismo se aplica a /property:property=value y su forma abreviada es /p. Puede encontrar más información sobre los argumentos disponibles en la documentación de dotnet msbuild.

  • -?|-h|--help

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

  • args

    Especifica argumentos adicionales que se van a pasar a las aplicaciones de prueba. Use un espacio para separar varios argumentos. Para obtener más información y ejemplos sobre qué pasar, consulte Información general de MTP y características de MTP.

    Sugerencia

    Para especificar argumentos adicionales para proyectos específicos, use la propiedad TestingPlatformCommandLineArguments MSBuild. Esta propiedad es especialmente útil cuando la solución combina marcos de pruebas (por ejemplo, MSTest y xUnit.net) o cuando solo algunos proyectos hacen referencia a una extensión determinada. Para obtener más información, consulte Soluciones con marcos de pruebas mixtas o extensiones.

Nota:

Para habilitar el registro de seguimiento en un archivo, use la variable de entorno DOTNET_CLI_TEST_TRACEFILE para proporcionar la ruta de acceso al archivo de seguimiento.

A partir de .NET 11 RC 1, dotnet test -bl usa una sesión de MSBuild para varias ejecuciones de proyecto, multi-destino y dispositivo, por lo que el registro binario contiene la compilación completa.

Comportamiento de salida y cancelación

A partir de .NET 11 versión preliminar 6, la salida interactiva de ANSI muestra las pruebas que se están ejecutando actualmente e notifican recuentos de pruebas por ensamblado. La pantalla de progreso permanece deshabilitada cuando se redirige la salida, anSI o la salida de progreso está deshabilitada o el entorno no es interactivo.

A partir de .NET 11 Preview 6, la primera ctrl+C deja de programar nuevas aplicaciones de prueba y solicitudes de cancelación cooperativa. Presione Ctrl+C de nuevo para finalizar los procesos secundarios inmediatamente. Una ejecución anulada se cierra con el código 3.

La salida de live test-host requiere un host MTP que admita el protocolo 1.1 o posterior. Los hosts más antiguos conservan la salida capturada y la reproducen para un módulo con errores. A partir de .NET 11 versión preliminar 7, los resúmenes de errores truncan la salida estándar capturada más de 40 líneas a las primeras 30 y últimas 10 líneas; los registros de diagnóstico conservan la salida completa.

En el caso de las ejecuciones de varios módulos, dotnet test evalúa el resultado de la prueba cero en la ejecución completa a partir de .NET 11 Preview 7. Un módulo sin pruebas no produce un error en la ejecución si otro módulo ejecuta correctamente las pruebas, a menos que una directiva de prueba mínima explícita requiera más pruebas.

Resultados y artefactos

Cuando el diseño de salida de artefactos del SDK está habilitado, .NET 11 RC 1 y versiones posteriores colocan informes mtP, archivos de cobertura y diagnósticos de <ArtifactsPath>/test/<project>/<pivot> forma predeterminada. Un valor explícito --results-directory o --results-directory-layout tiene prioridad.

A partir de .NET 11 RC 1 y MTP 2.4, las extensiones compatibles pueden realizar artefactos posteriores al proceso desde una ejecución de varios módulos. Por ejemplo, la extensión TRX puede crear un informe combinado al tiempo que conserva los informes por módulo. Para conocer los requisitos de extensión e informe, consulte Informes de prueba de MTP.

Reenvío de argumentos a la aplicación de prueba

dotnet test reenvía cualquier token que no reconoce a la aplicación de prueba. Cuando aparece una opción reconocida entre un nombre de opción no reconocido y su valor, quitar la opción reconocida puede cambiar cómo se enlazan los tokens de izquierda a las opciones de la aplicación de prueba. Para evitar esta ambigüedad, coloque los argumentos de la aplicación de prueba después de un literal --:

dotnet test --results-directory TestResults -- --report-trx --report-trx-filename A.trx

En el ejemplo anterior se requiere el Microsoft.Testing.Extensions.TrxReport paquete, ya sea como referencia de paquete directo o a través de una configuración del SDK de prueba que lo incluya.

El mismo comportamiento del analizador se aplica a dotnet run y dotnet build. Para obtener un ejemplo detallado, consulte Reenvío de argumentos a la aplicación en la dotnet run referencia.

Mínimo de ejecución completa y por módulo

Para --minimum-expected-tests, el -- separador determina el ámbito de la opción:

  • Los argumentos anteriores-- son globales. El dotnet test orquestador los interpreta para toda la ejecución.
  • Los argumentos después-- son locales. dotnet test los reenvía a cada módulo de prueba, por lo que cada módulo los aplica de forma independiente.

Dado --minimum-expected-tests que está disponible en ambos ámbitos, puede requerir un mínimo para toda la ejecución, para cada módulo o ambos:

dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

El comando anterior requiere al menos 5 pruebas en toda la ejecución y al menos 2 pruebas en cada módulo de prueba.

Los dos ámbitos cuentan pruebas omitidas de forma diferente:

Ámbito ¿Las pruebas omitidas se cuentan hacia el mínimo?
Global Yes. El dotnet test total agregado incluye pruebas omitidas.
Por módulo N.º MTP excluye las pruebas omitidas del número de pruebas que se ejecutaron.

A partir del SDK de .NET 11, el veredicto de pruebas cero para toda la ejecución se decide una vez a partir de los resultados agregados. Un módulo que no coincide con ninguna prueba, por ejemplo debido --test-modules a o a un global --filter, sale con el código 8 (ZeroTests), pero ese código se normaliza para que se realice correctamente antes de que se agreguen los resultados. Como resultado, un único módulo vacío no produce un error en toda la ejecución, aunque el módulo mantiene su Exit code: 8 diagnóstico en la salida para obtener visibilidad.

MTP 4.3.0 y versiones posteriores proporcionan --zero-tests-policy <allow-skipped|strict>. El valor predeterminado, allow-skipped, permite que un módulo todo omitido se realice correctamente. El strict valor trata las pruebas omitidas como no ejecutadas, por lo que un módulo todo omitido sale con el código 8. Pase la opción después de -- reenviarla a cada módulo de prueba:

dotnet test -- --zero-tests-policy strict

Cuando no establece un mínimo global, el SDK de .NET 11 determina el veredicto de pruebas cero de ejecución completa por separado. Una ejecución completa omitida se cierra con el código 8, independientemente del valor por módulo --zero-tests-policy .

Cuando se especifica --minimum-expected-tests y no se cumple el mínimo, se produce un error en la ejecución con el código de salida 9 (MinimumExpectedTestsPolicyViolation). Este código es distinto de 8 para que un mínimo global o por módulo más estricto no se confunda con un módulo vacío. Para que un mínimo por módulo devuelva el código 9 cuando el módulo ejecuta cero pruebas, el módulo de prueba debe usar MTP 4.4.0 o una versión posterior.

Nota:

--minimum-expected-tests 0 no es válido. Para suprimir el código de salida de pruebas cero, use --ignore-exit-code 8.

A partir de .NET 11 Versión preliminar 6, --tl, --terminalloggery --tlp se reenvía a MSBuild en lugar de a la aplicación de prueba. A partir de .NET 12 Preview 1, los formularios y -multiThreaded reconocidos -mt también se reenvieron a MSBuild. Para pasar una opción de aplicación con uno de estos nombres, colóquelo después --de .

Pase las opciones del modo de ejecución, como --help y --list-tests directamente a dotnet test. A partir de .NET 11 versión preliminar 6, el SDK valida el modo de ejecución negociado con la aplicación de prueba. Si un perfil de inicio o TestingPlatformCommandLineArguments inserta una de estas opciones, la operación del SDK solicitada y la operación de aplicación no coinciden y la ejecución produce un error con un diagnóstico.

Examples

  • Ejecute las pruebas en el project o la solución en el directorio actual:

    dotnet test

  • Ejecute las pruebas en el TestProject project:

    dotnet test --project ./TestProject/TestProject.csproj

  • Ejecute las pruebas en la solución TestProjects:

    dotnet test --solution ./TestProjects/TestProjects.sln

  • Ejecute las pruebas mediante el ensamblado TestProject.dll:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"

  • Ejecute las pruebas mediante TestProject.dll ensamblado con el directorio raíz:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"

  • Ejecute todos los proyectos de prueba a los que hace referencia un proyecto de recorrido con .NET 11 Versión preliminar 7 o posterior:

    dotnet test dirs.proj

  • Enumera las pruebas como JSON con .NET 11 Versión preliminar 7 o posterior:

    dotnet test --list-tests json

  • Ejecute una aplicación de prueba MTP basada en archivos de C# con .NET 12 Preview 1 o posterior:

    dotnet test App.Tests.cs

  • Ejecute las pruebas en el directorio actual con la extensión cobertura de código Microsoft. La aplicación de prueba debe hacer referencia a Microsoft.Testing.Extensions.CodeCoverage, ya sea directamente o a través de una configuración del SDK de prueba que lo incluya:

    dotnet test --coverage

  • Ejecute las pruebas y almacene los resultados en un directorio específico:

    dotnet test --results-directory ./TestResults

  • Ejecute las pruebas con la salida de diagnóstico en un directorio específico:

    dotnet test --diagnostic-output-directory ./Diagnostics

  • Ejecute las pruebas para garantizar que se ejecuten al menos 10 pruebas:

    dotnet test --minimum-expected-tests 10

  • Requerir al menos 5 pruebas en toda la ejecución y al menos 2 pruebas en cada módulo de prueba:

    dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

  • Ejecute las pruebas en el argumento TestProject project, proporcionando el argumento /-bl (registro binario) para msbuild:

    dotnet test --project ./TestProject/TestProject.csproj -bl

  • Ejecute las pruebas en el project, estableciendo la propiedad /> de MSBuild :

    dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"

Consulte también

  • Last updated on