Migre de VSTest a Microsoft. Testing.Platform (MTP)

En este artículo, aprenderá a migrar de VSTest a MTP.

Este artículo se centra en los pasos de migración y el mapeo de argumentos.

Si todavía necesita elegir una plataforma, comience con la introducción a las plataformas de prueba.

Si necesita un comportamiento detallado de dotnet test modos, consulte Pruebas con dotnet test.

Si necesita una sola lista de opciones de línea de comandos de la plataforma y de la extensión, consulte la referencia de opciones de la CLI de MTP.

Optar por usar MTP

El primer paso de la migración es participar en el uso de MTP.

Para todos los marcos de pruebas, agregue <OutputType>Exe</OutputType> a todos los proyectos de prueba de la solución. Después, siga las instrucciones específicas del marco.

MSTest (herramienta de pruebas de Microsoft)

MSTest admite MTP a partir de la versión 3.2.0. Sin embargo, se recomienda actualizar a la versión más reciente disponible de MSTest.

Para participar, agregue <EnableMSTestRunner>true</EnableMSTestRunner> debajo de un PropertyGroup en el archivo Directory.Build.props.

Nota:

Cuando se usa MSTest.Sdk, MTP se usa de forma predeterminada, a menos que <UseVSTest>true</UseVSTest> se especifique.

NUnit

MTP es compatible con NUnit3TestAdapter a partir de la versión 5.0.0.

Para participar, agregue <EnableNUnitRunner>true</EnableNUnitRunner> debajo de un PropertyGroup en el archivo Directory.Build.props.

xUnit.net

MTP es compatible a partir de xunit.v3.

Para participar, agregue <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> debajo de un PropertyGroup en el archivo Directory.Build.props.

dotnet test

Optar por el SDK de .NET 9 y anteriores

En .NET 9 SDK y versiones anteriores, no hay native compatibilidad con MTP para dotnet test. El soporte se construye sobre la infraestructura de VSTest. Para usarlo, agregue <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> debajo de un PropertyGroup en el archivo Directory.Build.props.

Importante

Al ejecutar soporte MTP en este modo, debe agregar -- para separar los dotnet test argumentos de los nuevos argumentos de plataforma. Por ejemplo: dotnet test --no-build -- --list-tests.

Suscribirse al SDK de .NET 10 y versiones más recientes

A partir del SDK de .NET 10, hay soporte nativo para MTP. Para usarlo, debe especificar el ejecutor de pruebas como Microsoft.Testing.Platform en global.json:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Importante

En este modo, ya no se utiliza el -- adicional.

Actualizar dotnet test invocaciones

Las opciones de línea de comandos de dotnet test se dividen en dos categorías: argumentos relacionados con la compilación y las relacionadas con pruebas.

Los argumentos relacionados con la compilación son irrelevantes para la plataforma de prueba y, como tal, no es necesario actualizar para la nueva plataforma. Los argumentos relacionados con la compilación se enumeran aquí:

  • -a|--arch <ARCHITECTURE>
  • --artifacts-path <ARTIFACTS_DIR>
  • -c|--configuration <CONFIGURATION>
  • -f|--framework <FRAMEWORK>
  • -e|--environment <NAME="VALUE">
  • --interactive
  • --no-build
  • --nologo
  • --no-restore
  • -o|--output <OUTPUT_DIRECTORY>
  • --os <OS>
  • -r|--runtime <RUNTIME_IDENTIFIER>
  • -v|--verbosity <LEVEL>

Los argumentos relacionados con pruebas son específicos de VSTest y, por tanto, deben transformarse para que coincidan con la nueva plataforma. En la tabla siguiente se muestra la asignación entre los argumentos VSTest y la nueva plataforma:

Argumento VSTest Nuevo argumento de plataforma
--test-adapter-path <ADAPTER_PATH> No es relevante para MTP
--blame No es relevante para MTP
--blame-crash --crashdump (requiere la extensión de volcado de memoria)
--blame-crash-dump-type <DUMP_TYPE> --crashdump-type (requiere la extensión de volcado de memoria)
--blame-crash-collect-always No está soportado
--blame-hang --hangdump (requiere la extensión hang dump)
--blame-hang-dump-type <DUMP_TYPE> --hangdump-type (requiere la extensión hang dump)
--blame-hang-timeout <TIMESPAN> --hangdump-timeout (requiere la extensión hang dump)
--collect <DATA_COLLECTOR_NAME> Depende del recopilador de datos
-d\|--diag <LOG_FILE> --diagnostic
--filter <EXPRESSION> Depende del marco de pruebas seleccionado.
-l\|--logger <LOGGER> Depende del registrador
--results-directory <RESULTS_DIR> --results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE> Depende del marco de pruebas seleccionado.
-t\|--list-tests --list-tests
-- <RunSettings arguments> --test-parameter (proporcionado por VSTestBridge)

--collect

--collect es un punto de extensibilidad general en VSTest para cualquier recopilador de datos. El modelo de extensibilidad de MTP es diferente y no hay ningún argumento centralizado que todos los recopiladores de datos usen. Con MTP, cada recopilador de datos puede agregar su propia opción de línea de comandos. Por ejemplo, la ejecución de Microsoft CodeCoverage a través de VSTest podría ser similar a la siguiente:

dotnet test --collect "Code Coverage;Format=cobertura"

Con MTP, esto se convierte en:

dotnet test --coverage --coverage-output-format cobertura

Importante

Como se explicó anteriormente, al usar MTP con VSTest, dotnet test se necesita un -- adicional antes de los argumentos destinados a pasarse a la plataforma. Por lo tanto, esto se convierte en dotnet test -- --coverage --coverage-output-format cobertura.

--filter

--filter es el filtro basado en VSTest.

MSTest y NUnit admiten el mismo formato de filtro incluso cuando se ejecutan con MTP.

xUnit.net, no admite el mismo formato de filtro cuando se ejecuta con MTP. Debe migrar desde el filtro basado en VSTest a la nueva compatibilidad con filtros en xunit.v3, que se proporciona mediante las siguientes opciones de línea de comandos.

xUnit.net opciones específicas:

  • --filter-class
  • --filter-not-class
  • --filter-method
  • --filter-not-method
  • --filter-namespace
  • --filter-not-namespace
  • --filter-trait
  • --filter-not-trait
  • --filter-query

Para obtener más información, consulte la documentación de Microsoft.Testing.Platform para xUnit.net y lenguaje de filtro de consulta para xUnit.net.

--logger

Lo que se conoce normalmente como "registrador" en VSTest se conoce como "periodista" en MTP. En MTP, el registro es explícitamente solo para fines de diagnóstico.

De forma similar a --collect, --logger es un punto de extensibilidad general en VSTest para cualquier registrador (o, en el contexto de MTP, cualquier periodista). Cada reportador de MTP tiene la libertad de agregar su propia opción de línea de comandos y, como tal, no hay ninguna opción centralizada como en VSTest --logger.

Uno de los registradores de VSTest muy usados es el registrador TRX. Normalmente, este registrador se denomina como sigue:

dotnet test --logger trx

Con MTP, el comando se convierte en:

dotnet test --report-trx

Importante

Para usar --report-trx, debe tener instalado el Microsoft.Testing.Extensions.TrxReport paquete NuGet.

Importante

Como se explicó anteriormente, al usar MTP con VSTest, dotnet test se necesita un -- adicional antes de pasar los argumentos destinados a la plataforma. Por lo tanto, esto se convierte en dotnet test -- --report-trx.

--settings

VSTest --settings se usa para especificar un archivo RunSettings para la ejecución de pruebas. RunSettings no es compatible con el MTP principal y se ha reemplazado por un archivo de configuración más moderno testconfig.json . Sin embargo, MSTest y NUnit siguen siendo compatibles con RunSettings antiguos al ejecutar MTP y --settings todavía se admite.

vstest.console.exe

Si usa vstest.console.exe directamente, se recomienda reemplazarlo por el dotnet test comando .

Explorador de pruebas

Al usar Visual Studio o Visual Studio Code Explorador de pruebas, es posible que tenga que habilitar la compatibilidad con MTP.

Visual Studio

Visual Studio Explorador de pruebas admite MTP a partir de la versión 17.14. Si usa una versión anterior, es posible que tenga que actualizar Visual Studio a la versión más reciente.

Visual Studio Code

Visual Studio Code con C# DevKit admite MTP.

Azure DevOps

Al usar tareas de Azure DevOps, puede que necesite actualizar su pipeline para usar MTP, dependiendo de la tarea que utilice.

Tarea VSTest

Si usa la tarea VSTest en Azure DevOps, puede reemplazarla por la tarea de .NET Core.

Tarea de la CLI de .NET Core

  • Si ha pasado arguments personalizado a la tarea, siga las mismas instrucciones para la migración de dotnet test.

  • Si usa la tarea DotNetCoreCLI sin optar por la experiencia nativa de MTP para .NET 10 SDK y versiones posteriores a través del archivo global.json, debe configurar la tarea arguments para que apunte correctamente al directorio de resultados al que solía apuntar, así como al informe TRX solicitado. Por ejemplo:

    - task: DotNetCoreCLI@2
  displayName: Run unit tests
  inputs:
    command: 'test'
    arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'

Diferencias de comportamiento entre VSTest y MTP

Ejecución de cero pruebas

Si un conjunto de pruebas ejecutó cero pruebas, VSTest lo tolera y sale con éxito. Sin embargo, MTP produce un error con el código de salida 8. Hay varias maneras de solucionar esto:

  • Pase --ignore-exit-code 8 al ejecutar las pruebas.

  • Si desea omitir ese código de salida para un proyecto de prueba específico, agregue lo siguiente en el archivo del proyecto:

    <PropertyGroup>
  <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
</PropertyGroup>

  • Utilice la variable de entorno TESTINGPLATFORM_EXITCODE_IGNORE.

Conservación de Console.InputEncoding

Si ejecuta las pruebas en una consola en la que se cambió explícitamente la página de códigos (por ejemplo, en Azure DevOps, la página de códigos se establece en 65001, que corresponde a UTF8), el comportamiento puede ser diferente entre VSTest y MTP.

  • Con MTP, esa codificación siempre se conserva.
  • Con VSTest no ejecutándose en modo de aislamiento (el comportamiento predeterminado de vstest.console), esa codificación se conserva, similar a MTP.
  • Con VSTest ejecutándose en modo de aislamiento (el comportamiento predeterminado de dotnet test), esa codificación no se conserva en el testhost, que es el proceso que ejecuta las pruebas.

Sugerencia

La razón por la que la codificación no se conserva con el modo de aislamiento vsTest es que el proceso testhost se inicia con CreateNoWindow = true. Por lo tanto, no está conectado a la consola original.

Si tiene una prueba que inicia otro proceso secundario y redirige su salida estándar, es posible que se produzcan problemas si se aplican todas las siguientes opciones:

  • La página de códigos de la consola se establece en 65001 (UTF8). Esto puede ocurrir en CI, pero generalmente no ocurre localmente. Para obtener un comportamiento local similar a en CI, ejecute chcp 65001 antes de ejecutar las pruebas.
  • El proceso secundario se inicia con una codificación que no es UTF-8. Esto también puede ocurrir si su propia prueba también establece CreateNoWindow = true.

Esto es especialmente problemático cuando el proceso secundario no espera ver el byte UTF8 BOM (Byte-Order-Mark), que podría obtener en el escenario anterior en .NET Framework.

Dado que es probable que esta diferencia de comportamiento sea problemática específicamente para el byte de BOM, una solución alternativa consiste en establecer InputEncoding durante la inicialización del ensamblado en UTF8 sin BOM:

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Una solución alternativa es no utilizar CreateNoWindow = true para los procesos secundarios que redirigen la entrada estándar.

  • Last updated on