Compartir por

Migración de MSTest v3 a v4

La versión estable MSTest v4 ya está disponible. En esta guía de migración se explora lo que ha cambiado en MSTest v4 y cómo puede migrar a esta versión.

Note

Por lo general, MSTest v4 no es compatible binariamente con MSTest v3. Cualquier biblioteca compilada en v3 debe volver a compilarse en v4.

Cambios importantes en el código fuente

Estos son cambios importantes que podrían provocar que los proyectos de prueba no se compilen.

Cambios importantes en TestMethodAttribute

Cambie TestMethodAttribute.Execute por TestMethodAttribute.ExecuteAsync

Si implementa su propio TestMethodAttribute, debe cambiar la sustitución Execute por ExecuteAsync. Este cambio se realizó para corregir errores de interbloqueo de larga duración causados por la naturaleza de bloqueo sincrónica de la API.

Por ejemplo, si anteriormente tenía lo siguiente:

public sealed class MyTestMethodAttribute : TestMethodAttribute
{
    public override TestResult[] Execute(ITestMethod testMethod)
    {
        // ...
        return result;
    }
}

Tendrá que cambiarlo a lo siguiente:

public sealed class MyTestMethodAttribute : TestMethodAttribute
{
    public override Task<TestResult[]> ExecuteAsync(ITestMethod testMethod)
    {
        // ...
        return Task.FromResult(result);
    }
}

TestMethodAttribute ahora usa atributos de información del autor de la llamada

El TestMethodAttribute constructor ha cambiado para tener parámetros que proporcionen atributos de información del autor de la llamada.

  • Si hereda de TestMethodAttribute, también debe proporcionar un compilador que propague la información a la clase base.

    public class MyTestMethodAttribute : TestMethodAttribute
{
    public MyTestMethodAttribute([CallerFilePath] string callerFilePath = "", [CallerLineNumber] int callerLineNumber = -1)
    : base(callerFilePath, callerLineNumber)
    {
    }
}

  • Si tiene aplicaciones de atributo como [TestMethodAttribute("Custom display name")], cambie a [TestMethodAttribute(DisplayName = "Custom display name")].

Tip

Un analizador con una corrección de código estará disponible próximamente para ayudarle con esta migración. Un solo clic en el IDE corregirá todas las instancias de la solución.

"Se elimina el enum ClassCleanupBehavior"

Ahora, los métodos ClassCleanup solo se ejecutan al final de la clase de prueba. Se ha eliminado la compatibilidad con la limpieza de clases al final del ensamblado. Si debe ejecutar la lógica de limpieza al final del ensamblado, hazlo en AssemblyCleanup en lugar de ClassCleanup. El comportamiento predeterminado de la limpieza de clases era anteriormente "EndOfAssembly", que los usuarios consideraban un error.

Si anteriormente tenía el código siguiente:

[ClassCleanup(ClassCleanupBehavior.EndOfClass)]
public static void ClassCleanup(TestContext testContext)
{
}

Tendrá que cambiarlo a lo siguiente:

[ClassCleanup]
public static void ClassCleanup(TestContext testContext)
{
}

TestContext.Properties ahora es IDictionary<string, object>

Anteriormente, TestContext.Properties era un IDictionary. Para mejorar la tipificación, ahora es IDictionary<string, object>.

Si tiene llamadas a TestContext.Properties.Contains, actualícelas a TestContext.Properties.ContainsKey.

Se ha eliminado la enumeración TestTimeout

Esta enumeración solo tenía un único miembro, , Infinitecuyo valor era int.MaxValue. Si tenía usos de [Timeout(TestTimeout.Infinite)], actualícelos a [Timeout(int.MaxValue)].

TestContext.ManagedType ahora se ha eliminado

Se quita la propiedad TestContext.ManagedType . En su lugar, use TestContext.FullyQualifiedTestClassName.

Los tipos no diseñados para el consumo público se hacen internos o se eliminan

  • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod se convierte en interno.
    • Tenga en cuenta que esta interfaz es diferente de ITestMethod en el ensamblado TestFramework, que no cambió.
    • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod no tiene ningún uso válido para los usuarios, por lo que se hizo interno.
  • Algunos de los tipos ya obsoletos se convierten en internos. Esto incluye:
    • MSTestDiscoverer
    • MSTestExecutor
    • AssemblyResolver
    • LogMessageListener
    • Gestor de Ejecución de Pruebas
    • TestMethodInfo
    • TestResultExtensions
    • UnitTestOutcomeExtensions
    • GenericParameterHelper
    • Tipos en el ensamblado de servicios de plataforma

Cambio en la firma de las API de Assert

  • Los APIs de aserción que aceptan parámetros message y object[] ahora solo aceptan message. Use la interpolación de cadenas en su lugar. Se ha realizado un cambio necesario para admitir la expresión de argumentos del llamador para las API de aserción.
  • Assert.AreEqual Se quitan las API de IEquatable<T> . Hay muy pocos usuarios de esta API y la API es engañosa. La mayoría de los usuarios no se ven afectados por esta eliminación, ya que la API no existía inicialmente en MSTest v3 y se introdujo en la versión 3.2.2.
    • Esta API también provoca problemas para los usuarios de F#. Por ejemplo, consulte fsharp/fslang-suggestions/issues/905.
    • Si estás afectado, obtendrás un error de compilación relacionado con la inferencia de tipos genéricos. Todo lo que debe hacer es especificar explícitamente el argumento de tipo como object.
  • Las API en desuso Assert.ThrowsException han sido eliminadas. Un analizador y un códigofijo en MSTest 3.10 le ayudan a migrar a las API más recientes.
  • Los usos de Assert.IsInstanceOfType<T>(x, out var t) ahora deben cambiar a var t = Assert.IsInstanceOfType<T>(x).
    • Las sobrecargas existentes que no tenían el parámetro out se han cambiado para devolver la instancia de tipo T en lugar de void. Esto solo supone un cambio importante para F#.

Se ha quitado la API ExpectedExceptionAttribute

Se quita la API en desuso ExpectedExceptionAttribute . Un analizador (MSTEST0006) y un codefijo en MSTest 3.2 le ayudarán a migrar a Assert.Throws.

Por ejemplo, si tenía el código siguiente:

[ExpectedException(typeof(SomeExceptionType))]
[TestMethod]
public void TestMethod()
{
    MyCall();
}

Usted (o el analizador y la corrección de código) debe cambiarlo por lo siguiente:

[TestMethod]
public void TestMethod()
{
    Assert.ThrowsExactly<SomeExceptionType>(() => MyCall());
}

Se han eliminado los marcos de destino no compatibles

Se ha eliminado la compatibilidad con los marcos de destino .NET Core 3.1 a .NET 7. La versión mínima admitida de .NET es .NET 8. Este cambio no afecta a .NET Framework. .NET Framework 4.6.2 sigue siendo el objetivo mínimo compatible de .NET Framework.

La estrategia de despliegue se ha trasladado de fuentes de datos individuales a TestMethodAttribute

La estrategia de implementación es una característica reciente introducida en MSTest 3.7 para solucionar las limitaciones conocidas. La propiedad se agregó en orígenes de datos individuales como DataRowAttribute y DynamicDataAttribute. Esta propiedad se ha trasladado a TestMethodAttribute.

ConditionBaseAttribute.ShouldRun Cambio de API

Se ha cambiado el nombre de la ConditionBaseAttribute.ShouldRun propiedad a IsConditionMet. Esto hace que sea más claro que ConditionMode no se debe usar en la implementación.

Se actualizan varios analizadores para que emitan advertencias por defecto.

La gravedad predeterminada de los analizadores siguientes cambió de Información a Advertencia:

Cambios disruptivos en el comportamiento

Estos son cambios importantes que podrían afectar al comportamiento en tiempo de ejecución.

DisableAppDomain ahora tiene como valor predeterminado true cuando se ejecuta en Microsoft.Testing.Platform

En la versión 4, y cuando se ejecuta con Microsoft.Testing.Platform, AppDomains se deshabilita de forma predeterminada (cuando no se especifica) ya que el aislamiento personalizado proporcionado es inútil en la mayoría de los casos y tiene un impacto importante en los rendimientos (hasta 30% más lento cuando se ejecuta bajo aislamiento).

Sin embargo, la característica sigue estando disponible. Si tiene escenarios que lo requieren, agregue la DisableAppDomain configuración en runsettings.

TestContext lanza una excepción cuando se utiliza incorrectamente

El TestContext tipo se pasa a AssemblyInitialize, ClassInitialize y a las pruebas, pero la información disponible en cada fase es diferente. Ahora, se produce una excepción al acceder a una propiedad relacionada con una información de ejecución de prueba como parte de AssemblyInitialize o ClassInitialize.

  • TestContext.FullyQualifiedTestClassName no se puede tener acceso a él en la inicialización del ensamblado.
  • TestContext.TestName no se puede tener acceso a él en la inicialización del ensamblado ni en la inicialización de clase.

El estado de TestCase.Id está cambiando

Para solucionar errores pendientes prolongados que muchos usuarios presentaron, la generación de TestCase.Id ha cambiado. Esto afecta a las características de Azure DevOps, por ejemplo, el seguimiento de errores de prueba a lo largo del tiempo.

TreatDiscoveryWarningsAsErrors ahora tiene como valor predeterminado true

v4 usa valores predeterminados más estrictos. Por lo tanto, el valor predeterminado de TreatDiscoveryWarningsAsErrors es ahora true. Debe ser un cambio transparente para la mayoría de los usuarios y ayudar a otros usuarios a descubrir errores ocultos.

MSTest.Sdk ya no agrega Microsoft.NET.Test.Sdk referencia al usar Microsoft.Testing.Platform

De forma predeterminada, MSTest.Sdk usa Microsoft.Testing.Platform. Si la UseVSTest propiedad MSBuild se establece en true, usará VSTest en su lugar. En MSTest 3.x, el SDK agregó una referencia a Microsoft.NET.Test.Sdk (que aporta compatibilidad con VSTest) incluso cuando se usa Microsoft.Testing.Platform. Esta referencia de paquete no es necesaria cuando se ejecuta con Microsoft.Testing.Platform y se ha quitado en MSTest v4.

Si desea tener compatibilidad con VSTest (por ejemplo, si quiere ejecutar con vstest.console), debe agregar manualmente una referencia de paquete del paquete NuGet a su Microsoft.NET.Test.Sdk proyecto.

  • Last updated on