Compartir a través de


prueba dotnet con Microsoft.Testing.Platform (MTP)

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

Nombre

dotnet test - Controlador de pruebas de .NET usado para ejecutar pruebas unitarias con Microsoft.Testing.Platform.

Sinopsis

dotnet test
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>] 
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-restore]
    [--no-ansi]
    [--no-progress]
    [--output <VERBOSITY_LEVEL>]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [<args>...]

dotnet test -h|--help

Description

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

Advertencia

Cuando Microsoft.Testing.Platform participa mediante global.json, dotnet test espera que todos los proyectos de prueba usen Microsoft.Testing.Platform. Se trata de un error si alguno de los proyectos de prueba usa VSTest.

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ícitamente tiene sentido, como compilaciones de integración continua 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, --solutiono --test-modules. Estas opciones no se pueden combinar. Además, al usar --test-modules, no puede especificar --arch, --configuration, --framework, --oso --runtime. Estas opciones no son relevantes para un módulo ya compilado.

  • --project <PROJECT_PATH>

    Especifica la ruta de acceso del archivo del proyecto que se va a ejecutar (nombre de la 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 el globbing de archivos en .NET. Solo se ejecutarán las pruebas que pertenecen a esos módulos de prueba. Para obtener más información y ejemplos sobre cómo usar el globbing de archivos en .NET, consulte archivo globbing.

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

  • -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 a partir de .NET 6 (versión preliminar 7).

  • -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 proyecto.

  • -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 del proyecto.

  • --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 a partir de .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Runtime de destino que probar.

    Forma abreviada -r disponible a partir del SDK de NET 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 proyecto individual en su lugar.

  • -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 proyecto de prueba no se compila antes de ejecutarse. También establece implícitamente la marca --no-restore.

  • --no-restore

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

  • --no-ansi

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

  • --no-progress

    Deshabilita el progreso de los informes en pantalla.

  • --output <VERBOSITY_LEVEL>

    Especifica el nivel de detalle de salida al notificar pruebas. Los valores válidos son Normal y Detailed. El valor predeterminado es Normal.

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

  • --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 Microsoft.Testing.Platform y extensiones Microsoft.Testing.Platform.

    Sugerencia

    Para especificar argumentos adicionales para proyectos específicos, use la propiedad TestingPlatformCommandLineArguments MSBuild.

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.

Examples

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

    dotnet test
    
  • Ejecute las pruebas en el proyecto TestProject:

    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 las pruebas en el directorio actual con cobertura de código:

    dotnet test --coverage
    
  • Ejecute las pruebas del proyecto TestProject proporcionando el argumento (registro binario) -bl a msbuild:

    dotnet test --project ./TestProject/TestProject.csproj -bl
    
  • Ejecute las pruebas del proyecto TestProject y establezca la propiedad DefineConstantsMSBuild en DEV:

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

Consulte también