Condividi tramite

Eseguire la migrazione da MSTest v3 a v4

La versione stabile MSTest v4 è ora disponibile. Questa guida alla migrazione illustra le modifiche apportate a MSTest v4 e come eseguire la migrazione a questa versione.

Note

In generale, MSTest v4 non è compatibile a livello binario con MSTest v3. Qualsiasi libreria compilata in base alla versione 3 deve essere ricompilata rispetto alla versione 4.

Modifiche che interrompono la compatibilità del codice sorgente

Queste sono modifiche significative che potrebbero causare il fallimento della compilazione dei tuoi progetti di test.

Modifiche che causano un'interruzione di TestMethodAttribute

Modificare TestMethodAttribute.Execute in TestMethodAttribute.ExecuteAsync

Se si implementa il proprio TestMethodAttribute, è necessario modificare l'override Execute in ExecuteAsync. Questa modifica è stata apportata per correggere bug di deadlock di lunga durata causati dalla natura sincrona di blocco dell'API.

Ad esempio, se in precedenza si disponeva di quanto segue:

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

Sarà necessario modificarlo nel modo seguente:

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

TestMethodAttribute ora usa gli attributi delle informazioni sul chiamante

Il TestMethodAttribute costruttore è stato modificato in modo da avere parametri che forniscono attributi di informazioni sul chiamante.

  • Se si eredita da TestMethodAttribute, è necessario fornire anche un costruttore di questo tipo che propaga le informazioni alla classe base.

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

  • Se sono presenti applicazioni di attributi come [TestMethodAttribute("Custom display name")], passare a [TestMethodAttribute(DisplayName = "Custom display name")].

Tip

Un analizzatore con una correzione del codice sarà presto disponibile per aiutarti con questa migrazione. Un singolo clic nell'IDE correggerà tutte le istanze nella soluzione.

L'enumerazione ClassCleanupBehavior viene rimossa

A questo punto, i metodi ClassCleanup vengono eseguiti solo alla fine della classe di test. Il supporto per la procedura di pulizia delle classi, da eseguire alla fine dell'assembly, è stato rimosso. Se è necessario eseguire la logica di pulizia finale dell'assembly, farlo in AssemblyCleanup piuttosto che in ClassCleanup. Il comportamento predefinito della pulizia della classe era precedentemente "EndOfAssembly", che gli utenti consideravano un bug.

Se in precedenza era presente il codice seguente:

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

Sarà necessario modificarlo nel modo seguente:

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

TestContext.Properties è ora stringa IDictionary<, oggetto>

In precedenza, TestContext.Properties era un oggetto IDictionary. Per migliorare l'esperienza di digitazione, è ora IDictionary<string, object>.

Se hai chiamate a TestContext.Properties.Contains, aggiornale a TestContext.Properties.ContainsKey.

L'enumerazione TestTimeout viene rimossa

Questa enumerazione ha solo un singolo membro, Infinite, il cui valore era int.MaxValue. Se ci sono utilizzi di [Timeout(TestTimeout.Infinite)], aggiornarli a [Timeout(int.MaxValue)].

TestContext.ManagedType è stato rimosso

La proprietà TestContext.ManagedType viene rimossa. Utilizzare invece TestContext.FullyQualifiedTestClassName.

I tipi non destinati all'utilizzo pubblico vengono resi interni o rimossi

  • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod è reso interno.
    • Si noti che questa interfaccia è diversa da ITestMethod nell'assembly TestFramework, che non è stata modificata.
    • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod non ha utilizzi validi per gli utenti, quindi è stato reso interno.
  • Alcuni tipi ormai obsoleti vengono resi interni. ad esempio:
    • MSTestDiscoverer
    • MSTestExecutor
    • AssemblyResolver
    • LogMessageListener
    • TestExecutionManager
    • TestMethodInfo
    • TestResultExtensions
    • UnitTestOutcomeExtensions
    • GenericParameterHelper
    • Tipi di servizi della piattaforma nell'assembly

Cambio nella firma delle API Assert

  • Le API Assert che accettano sia i parametri message che object[] ora accettano solo message. Usare invece l'interpolazione di stringhe. Si tratta di una modifica necessaria per supportare l'espressione di argomento del chiamante per le API di asserzione.
  • Assert.AreEqual Le API per IEquatable<T> vengono rimosse. Ci sono pochissimi utenti di questa API e l'API è fuorviante. La maggior parte degli utenti non è interessata da questa rimozione, perché l'API non esisteva inizialmente in MSTest v3 ed è stata introdotta nella versione 3.2.2.
    • Questa API causa anche problemi per gli utenti F#. Ad esempio, vedere fsharp/fslang-suggestions/issues/905.
    • Se sei interessato, verrà visualizzato un errore di compilazione sull'inferenza del tipo generico. È sufficiente specificare in modo esplicito l'argomento di tipo come object.
  • Le API deprecate Assert.ThrowsException vengono rimosse. Un analizzatore e un prefisso in MSTest 3.10 consentono di eseguire la migrazione alle API più recenti.
  • Gli utilizzi di Assert.IsInstanceOfType<T>(x, out var t) dovrebbero ora cambiare in var t = Assert.IsInstanceOfType<T>(x).
    • Gli overload esistenti che non avevano il parametro out sono stati modificati per restituire l'istanza di tipo T anziché void. Si tratta solo di una modifica che causa un'interruzione per F#.

L'API ExpectedExceptionAttribute viene rimossa

L'API deprecata ExpectedExceptionAttribute viene rimossa. Un analizzatore (MSTEST0006) e un prefisso di codice in MSTest 3.2 consentono di eseguire la migrazione a Assert.Throws.

Ad esempio, se si dispone del codice seguente:

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

Lei (o l'analizzatore e la correzione del codice) deve cambiarlo nel modo seguente:

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

Sono stati eliminati i framework di destinazione non supportati

Il supporto per i framework da .NET Core 3.1 a .NET 7 è stato eliminato. La versione minima supportata di .NET è .NET 8. Questa modifica non influisce su .NET Framework. .NET Framework 4.6.2 continua a essere il target minimo supportato di .NET Framework.

Strategia di dispiegamento spostata da singole origini dati a TestMethodAttribute

La strategia di apertura è una funzionalità recente introdotta in MSTest 3.7 per aggirare le limitazioni note. La proprietà è stata aggiunta in singole origini dati, ad esempio DataRowAttribute e DynamicDataAttribute. Questa proprietà è stata spostata in TestMethodAttribute.

ConditionBaseAttribute.ShouldRun Modifica API

La ConditionBaseAttribute.ShouldRun proprietà è stata rinominata in IsConditionMet. Ciò rende più chiaro che ConditionMode non deve essere usato nell'implementazione.

Per impostazione predefinita, più analizzatori sono aggiornati per mostrare avvisi

La gravità predefinita degli analizzatori seguenti è cambiata da Info a Avviso:

Modifiche che causano un'interruzione del comportamento

Si tratta di modifiche significative che potrebbero influire sul comportamento del sistema durante l'esecuzione.

DisableAppDomain ora è impostato su true quando è in esecuzione in Microsoft.Testing.Platform

Nella versione 4 e quando vengono eseguiti con Microsoft.Testing.Platform, i domini app vengono disabilitati per impostazione predefinita (se non specificato) perché l'isolamento personalizzato fornito è inutile nella maggior parte dei casi e ha un impatto importante sulle prestazioni (fino a 30% più lento quando viene eseguito in isolamento).

Tuttavia, la funzionalità rimane disponibile. Se sono presenti scenari che lo richiedono, aggiungere l'impostazione DisableAppDomain in runsettings.

Importante

Quando l'isolamento di AppDomain è abilitato, MSTest scarica l'AppDomain al termine di tutti i test, che interrompe tutti i thread associati all'AppDomain, inclusi i thread in primo piano. Di conseguenza, se si dispone di un thread in primo piano in esecuzione per sempre in MSTest v3, l'esecuzione del test verrà completata correttamente. Lo stesso scenario si blocca in MSTest v4, che è un comportamento ideale perché il processo non deve uscire quando un thread in primo piano è ancora in esecuzione.

TestContext genera un'eccezione quando viene usata in modo non corretto

Il TestContext tipo viene passato a AssemblyInitialize, ClassInitialize e ai test, ma le informazioni disponibili in ogni fase sono diverse. Viene ora generata un'eccezione quando si accede a una proprietà correlata a informazioni sull'esecuzione di test come parte di AssemblyInitialize o ClassInitialize.

  • TestContext.FullyQualifiedTestClassName non può essere accessibile nell'inizializzazione dell'assembly.
  • TestContext.TestName non può essere accessibile durante l'inizializzazione dell'assembly o della classe.

TestCase.Id sta cambiando

Per risolvere i bug di lunga data che molti utenti hanno segnalato, la generazione di TestCase.Id è cambiata. Ciò influisce sulle funzionalità di Azure DevOps, ad esempio il rilevamento degli errori di test nel tempo.

TreatDiscoveryWarningsAsErrors ora è impostato su "vero" di default

v4 usa valori predefiniti più rigidi. Di conseguenza, il valore predefinito di TreatDiscoveryWarningsAsErrors è ora true. Questo dovrebbe essere un cambiamento trasparente per la maggior parte degli utenti e dovrebbe aiutare altri utenti a individuare bug nascosti.

MSTest.Sdk non aggiunge più riferimenti Microsoft.NET.Test.Sdk quando si usa Microsoft.Testing.Platform

Per impostazione predefinita, MSTest.Sdk usa Microsoft.Testing.Platform. Se la UseVSTest proprietà MSBuild è impostata su true, userà invece VSTest. In MSTest 3.x l'SDK ha aggiunto un riferimento a Microsoft.NET.Test.Sdk (che offre supporto VSTest) anche quando si usa Microsoft.Testing.Platform. Questo riferimento al pacchetto non è necessario quando viene eseguito con Microsoft.Testing.Platform ed è stato rimosso in MSTest v4.

Se si vuole comunque che VSTest sia supportato (ad esempio, se si vuole eseguire con vstest.console), è necessario aggiungere manualmente un riferimento al Microsoft.NET.Test.Sdk pacchetto NuGet al progetto.

  • Last updated on