Configuración del SDK de MSTest

En este artículo se tratan las opciones de configuración avanzadas para MSTest.Sdk. Para la configuración básica e inicio, consulte Introducción a MSTest.

Importante

De forma predeterminada, MSTest.Sdk usa el ejecutor de MSTest con MTP, incluida la prueba de dotnet. Esto requiere modificar las llamadas de CI y la CLI local, y también afecta las entradas disponibles de .runsettings. Para mantener las integraciones y herramientas antiguas , cambie a VSTest.

MSTest.Sdk establece EnableMSTestRunner y TestingPlatformDotnetTestSupport en true de forma predeterminada. Para obtener más información sobre la prueba de dotnet y sus diferentes modos, consulte Pruebas con prueba de dotnet.

Bibliotecas auxiliares de utilidad para pruebas

Si el project que usa MSTest.Sdk está diseñado para ser una biblioteca auxiliar de utilidad de prueba y no contiene ninguna prueba ejecutable, el project debe tener <IsTestApplication>false</IsTestApplication>.

Selecciona el corredor

De forma predeterminada, el SDK de MSTest se basa en MTP, pero puede cambiar a VSTest agregando la propiedad <UseVSTest>true</UseVSTest>.

Extender MTP

Puede personalizar la experiencia de MTP a través de un conjunto de extensiones de paquete NuGet. Para simplificar y mejorar esta experiencia, el SDK de MSTest presenta dos características:

perfil de Microsoft.Testing.Platform

El concepto de profiles permite seleccionar el conjunto predeterminado de configuraciones y extensiones que se aplicarán al project de prueba.

Puede establecer el perfil mediante la propiedad TestingExtensionsProfile con uno de los tres perfiles siguientes:

  • None: no hay extensiones habilitadas.

  • Default: habilita las extensiones recomendadas para esta versión de MSTest.SDK. Este es el valor predeterminado cuando la propiedad no se establece explícitamente.

    Habilita las siguientes extensiones:

  • AllMicrosoft- Habilita las extensiones de Microsoft seleccionadas para un uso completo, incluidas las extensiones con una licencia restrictiva. Las extensiones experimentales y solo de API pueden seguir requiriendo una activación explícita.

    Habilita todas las extensiones del Default perfil, además de las siguientes extensiones:

    En las versiones 3.11.0 a 4.2.x de MSTest.Sdk, la extensión Azure DevOps Report solo se incluye en AllMicrosoft.

Nota:

Los perfiles hacen referencia a los paquetes de informes de Azure DevOps y Acciones de GitHub, pero la generación de informes sigue deshabilitada en tiempo de ejecución. Pase --report-azdo para habilitar los informes de Azure DevOps. Para habilitar los informes de Acciones de GitHub, ejecute las pruebas en Acciones de GitHub y supere --report-gh.

Este es un ejemplo completo de uso del perfil None:

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <TestingExtensionsProfile>None</TestingExtensionsProfile>
    </PropertyGroup>

</Project>
Extensión/Perfil Ninguno Predeterminado AllMicrosoft
Cobertura de código ✔️ ✔️
Volcado de memoria ✔️
Falsificaciones ✔️¹
Volcado de memoria de bloqueo ✔️
Recarga activa ✔️
Informe HTML ✔️
informe de Acciones de GitHub ✔️³ ✔️³
Reintentar ✔️
Trx ✔️ ✔️
informe de Azure DevOps ✔️³ ✔️²

¹ MSTest.Sdk 3.7.0+ ² MSTest.Sdk 3.11.0+ ³ MSTest.Sdk 4.3.0+

Habilitación o deshabilitación de extensiones

Las propiedades de MSBuild pueden habilitar y deshabilitar las extensiones con el patrón Enable[NugetPackageNameWithoutDots].

Por ejemplo, para habilitar la extensión de volcado de memoria (paquete NuGet Microsoft.Testing.Extensions.CrashDump), puede usar la siguiente propiedad EnableMicrosoftTestingExtensionsCrashDump establecida en true:

<Project Sdk="MSTest.Sdk/4.1.0">

<PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <EnableMicrosoftTestingExtensionsCrashDump>true</EnableMicrosoftTestingExtensionsCrashDump>
</PropertyGroup>

</Project>

Para obtener una lista de todas las extensiones disponibles, consulte Características de MTP.

Algunas extensiones de MTP siguen siendo opcionales y no se incluyen en los perfiles Default o AllMicrosoft:

  • A partir de MSTest.Sdk 4.3, establezca <EnableMicrosoftTestingExtensionsJUnitReport>true</EnableMicrosoftTestingExtensionsJUnitReport> y, después, pase --report-junit.
  • A partir de la versión preliminar de MSTest.Sdk 4.4, establezca <EnableMicrosoftTestingExtensionsCtrfReport>true</EnableMicrosoftTestingExtensionsCtrfReport>y, a continuación, pase --report-ctrf.
  • Para hacer referencia a la extensión OpenTelemetry, establezca <EnableMicrosoftTestingExtensionsOpenTelemetry>true</EnableMicrosoftTestingExtensionsOpenTelemetry>. Dado que la extensión requiere configuración de API, regístrela en el punto de entrada personalizado, como se describe en OpenTelemetry.

Estas extensiones solo están disponibles con MTP.

Advertencia

Es importante revisar los términos de licencia de cada extensión, ya que pueden variar.

Las extensiones habilitadas y deshabilitadas se combinan con las extensiones proporcionadas por el perfil de extensión seleccionado.

Este patrón de propiedad se puede usar para habilitar una extensión adicional sobre el perfil Default implícito (como se ve en el ejemplo anterior de CrashDumpExtension).

También puede deshabilitar una extensión que provenga del perfil seleccionado. Por ejemplo, deshabilite la extensión MS Code Coverage estableciendo <EnableMicrosoftTestingExtensionsCodeCoverage>false</EnableMicrosoftTestingExtensionsCodeCoverage>:

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnableMicrosoftTestingExtensionsCodeCoverage>false</EnableMicrosoftTestingExtensionsCodeCoverage>
    </PropertyGroup>

</Project>

En MSTest.Sdk 4.3.0 y versiones posteriores, el Default perfil hace referencia a los paquetes Azure DevOps Report y Acciones de GitHub Report. Para quitar cualquier referencia de paquete, establezca <EnableMicrosoftTestingExtensionsAzureDevOpsReport>false</EnableMicrosoftTestingExtensionsAzureDevOpsReport> o <EnableMicrosoftTestingExtensionsGitHubActionsReport>false</EnableMicrosoftTestingExtensionsGitHubActionsReport>. Si mantienes las referencias a los paquetes, los informes de Azure DevOps solo se inician cuando pasas --report-azdo. La generación de informes de Acciones de GitHub solo comienza cuando ejecutas las pruebas en Acciones de GitHub y pasas --report-gh.

Características

Además de la selección del ejecutor y de las extensiones específicas del ejecutor, MSTest.Sdk también proporciona características adicionales para simplificar y mejorar la experiencia de prueba.

Prueba con Aspire

Aspire es una pila con opinión preparada para la nube para compilar aplicaciones observables, listas para producción y distribuidas. Aspire se entrega a través de una colección de paquetes NuGet que gestionan aspectos específicos de la nube nativa. Para obtener más información, consulte los Aspire documentos.

Nota:

Esta característica está disponible en MSTest.Sdk 3.4.0.

Al establecer la propiedad EnableAspireTesting en true, puede traer todas las dependencias y directivas predeterminadas using que necesita para realizar pruebas con Aspire y MSTest.

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnableAspireTesting>true</EnableAspireTesting>
    </PropertyGroup>

</Project>

Prueba con Playwright

Playwright permite pruebas de un extremo a otro confiables para web apps modernas. Para obtener más información, consulte la documentación de Playwright oficial.

Nota:

Esta característica está disponible en MSTest.Sdk 3.4.0.

Al establecer la propiedad EnablePlaywright en true, puede traer todas las dependencias y directivas predeterminadas using que necesita para realizar pruebas con Playwright y MSTest.

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnablePlaywright>true</EnablePlaywright>
    </PropertyGroup>

</Project>

Migración al SDK de MSTest

Tenga en cuenta los pasos siguientes, que son necesarios para migrar al SDK de MSTest.

Actualiza tu proyecto

Al migrar un proyecto de prueba de MSTest existente al SDK de MSTest, comience reemplazando la entrada Sdk="Microsoft.NET.Sdk" en la parte superior del proyecto de prueba con Sdk="MSTest.Sdk"

- Sdk="Microsoft.NET.Sdk"
+ Sdk="MSTest.Sdk"

Agregue la versión al global.json:

{
    "msbuild-sdks": {
        "MSTest.Sdk": "4.1.0"
    }
}

A continuación, puede empezar a simplificar el proyecto.

Elimine las propiedades predeterminadas:

- <EnableMSTestRunner>true</EnableMSTestRunner>
- <OutputType>Exe</OutputType>
- <IsPackable>false</IsPackable>
- <IsTestProject>true</IsTestProject>

Elimine las referencias de paquete predeterminadas:

- <PackageReference Include="MSTest"
- <PackageReference Include="MSTest.TestFramework"
- <PackageReference Include="MSTest.TestAdapter"
- <PackageReference Include="MSTest.Analyzers"
- <PackageReference Include="Microsoft.NET.Test.Sdk"

Por último, en función del perfil de extensiones que usa, también puede quitar algunos de los paquetes de Microsoft.Testing.Extensions.*.

Actualice su CI

Una vez que haya actualizado los proyectos, si usa MTP (valor predeterminado) y si confía en dotnet test para ejecutar las pruebas, debe actualizar la configuración de CI. Para obtener más información y orientarle sobre todos los cambios necesarios, consulte Integración de pruebas de dotnet.

Si usas el modo VSTest de dotnet test, aquí tiene un ejemplo de actualización al usar la tarea DotNetCoreCLI en Azure DevOps.

El perfil de extensión predeterminado de MSTest.Sdk proporciona los paquetes Microsoft.Testing.Extensions.TrxReport y Microsoft.Testing.Extensions.CodeCoverage que requieren las opciones agregadas. Si selecciona el perfil None, habilite o haga referencia a ambas extensiones antes de usar las opciones.

\- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: '**/**.sln'
-    arguments: '--configuration Release'
+    arguments: '--configuration Release -- --report-trx --results-directory $(Agent.TempDirectory) --coverage'

Generador de origen de reflexión

Importante

El siguiente comportamiento de MSTest 4.4 solo está disponible en compilaciones en versión preliminar hasta que se publique MSTest 4.4.0.

MSTest 4.3 introdujo el generador de código fuente basado en reflexión en el paquete experimental MSTest.SourceGeneration, versionado de forma independiente. A partir de MSTest 4.4, el paquete se graduó del estado experimental y usa la versión de MSTest.

Los proyectos de AOT nativos incluyen el generador de origen automáticamente. Para un proyecto que no sea NativeAOT y que use MSTest.Sdk, habilítelo con <EnableMSTestSourceGeneration>true</EnableMSTestSourceGeneration>. MSTest.Sdk alinea las versiones MSTest.SourceGeneration, MSTest.TestFramework y MSTest.TestAdapter mediante MSTestVersion.

El SDK también admite la generación de origen en bibliotecas de pruebas reutilizables y proyectos que usan administración central de paquetes. Proporciona los correspondientes ganchos de tiempo de ejecución MSTest.TestAdapter y genera los elementos necesarios PackageVersion.

.NET Standard no admite estos puntos de enlace en tiempo de ejecución. Al habilitar la generación de origen para un destino estándar de .NET, el SDK notifica este error:

La generación de código fuente de MSTest no es compatible con los marcos de destino de .NET Estándar, ya que los hooks de tiempo de ejecución de MSTest.TestAdapter necesarios no están disponibles.

El generador de origen detecta pruebas en tiempo de compilación. Cuando el generador está activo, las clases de prueba deben declarar [TestClass] directamente en lugar de heredarlo. El analizador de MSTEST0069 marca las clases que se basan en un elemento [TestClass]heredado.

A partir de MSTest 4.3.2, MSTestSourceGenMode tiene como valor predeterminado ReflectionFree para los proyectos recortados y de AOT nativo. Este modo usa metadatos e invocadores generados cuando es compatible con la estructura de prueba. En los entornos de ejecución que admiten reflexión, MSTest recurre a la reflexión cuando faltan entradas generadas o estas no son compatibles.

A partir de MSTest 4.4, la generación sin reflexión materializa metadatos de atributo heredados completos, incluidos AttributeUsage y AllowMultiple. En MTP, puede omitir la detección y la validación en tiempo de ejecución para los métodos sincrónicos simples [DataRow] y [TestMethod]. Las pruebas asincrónicas, los atributos personalizados de método de prueba, DynamicData, las implementaciones personalizadas de ITestDataSource y las estructuras de prueba ambiguas usan la vía alternativa. VSTest también conserva su ruta de acceso existente.

El modo sin reflexión notifica estos diagnósticos:

ID Forma de prueba no admitida
AOTSG0001 Clase de prueba estática
AOTSG0002 Clase de prueba genérica abierta, incluida una clase anidada en un tipo genérico.
AOTSG0003 Clases a las que el código generado no puede acceder, incluidas las clases locales de un archivo o las anidadas privadas o privadas-protegidas.
AOTSG0004 Método de prueba genérico
AOTSG0005 Método de prueba con un parámetro ref, in o out

Características experimentales

Las siguientes características de MSTest 4.3 son experimentales. Sus API públicas están sujetas a cambios y se muestran tras diagnósticos experimentales. Para participar, confirme el identificador de diagnóstico correspondiente.

Filtrado programático de pruebas con ITestFilter

Nota:

Introducido en MSTest 4.3.0 (experimental).

El punto de extensión experimental ITestFilter, registrado a través de [TestFilterProviderAttribute], permite decidir mediante programación si debe ejecutarse cada prueba antes de que se cargue cualquier clase de prueba. Esto resulta útil para la lógica de selección personalizada que no se puede expresar con filtros de línea de comandos.

Implemente ITestFilter.Filter(TestFilterContext) para inspeccionar los metadatos sin cargar la clase de prueba:

public sealed class MyFilter : ITestFilter
{
    public TestFilterResult Filter(TestFilterContext context) =>
        context.DisplayName.Contains("Nightly", StringComparison.Ordinal)
            ? TestFilterResult.Run : TestFilterResult.Drop;
}

Devuelve TestFilterResult.Run para ejecutar la prueba, Drop para omitirla sin resultado o Skip(reason) para informar de un resultado omitido. MSTest puede llamar de manera concurrente a una misma instancia de filtro, por lo que las implementaciones deben ser seguras para los subprocesos. Los filtros de la línea de comandos y del explorador de pruebas se ejecutan antes de ITestFilter, mientras que [Ignore] se evalúa después.

A partir de MSTest 4.4, los proyectos de .NET pueden usar el formulario [assembly: TestFilterProvider<MyFilter>]de registro genérico y seguro para tipos . A continuación, el compilador garantiza que MyFilter implementa ITestFilter y tiene un constructor público sin parámetros. El atributo genérico no está disponible para .NET Framework. Para un proyecto de destino múltiple, seleccione el formulario genérico o no genérico con un símbolo de preprocesador de plataforma de destino.

#if NET
[assembly: TestFilterProvider<MyFilter>]
#else
[assembly: TestFilterProvider(typeof(MyFilter))]
#endif

A partir de MSTest 4.4, el analizador de MSTEST0081 valida completamente el formulario de registro no genérico. En el caso del formulario genérico, sigue informando de tipos de filtro genéricos y ensamblados que registran más de un proveedor.

TestRun.Current y pruebas planeadas

Nota:

Introducido en MSTest 4.3.0 (experimental).

La API experimental TestRun.Current (de RFC 014) expone información sobre la ejecución actual, incluido el conjunto de pruebas planeadas, por lo que las extensiones y los accesorios pueden inspeccionar lo que está programado para ejecutarse.

Limitaciones conocidas

Los SDK de MSBuild proporcionados por NuGet (incluido MSTest.Sdk) tienen compatibilidad con herramientas delimitadas cuando se trata de actualizar su versión, lo que significa que la interfaz de usuario habitual de NuGet y Visual Studio para administrar paquetes NuGet no funciona según lo previsto. Deberá actualizar manualmente la versión en el archivo global.json y en el archivo del proyecto. (Esto se aplica incluso si usa Dependabot debido a problemas dependabot-core#12824 y dependabot-core#8615).

Consulte también

  • Last updated on