Бөлісу құралы:


Миграция из MSTest версии 3 в версию 4

Теперь доступна стабильная версия MSTest версии 4. В этом руководстве по миграции рассматриваются изменения в MSTest версии 4 и способах миграции на эту версию.

Note

Как правило, MSTest версии 4 не является бинарно совместимым с MSTest версии 3. Любая библиотека, скомпилированная против версии 3, должна быть перекомпилирована по версии 4.

Изменения, нарушающие работу исходного кода

Это критические изменения, которые могут привести к сбою компиляции тестовых проектов.

Несовместимые изменения TestMethodAttribute

Изменение TestMethodAttribute.Execute на TestMethodAttribute.ExecuteAsync

Если вы реализуете собственный TestMethodAttribute, необходимо изменить переопределение Execute на ExecuteAsync. Это изменение было внесено для исправления давних ошибок взаимоблокировки, вызванных синхронным характером блокировки API.

Например, если у вас ранее было следующее:

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

Вам потребуется изменить его на следующее:

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

TestMethodAttribute теперь использует атрибуты сведений о вызывающем объекте

Конструктор TestMethodAttribute был изменен, чтобы включать параметры, предоставляющие атрибуты информации о вызывающем.

  • Если вы наследуете от TestMethodAttribute, вы должны также указать такой конструктор, который передает информацию базовому классу.

    public class MyTestMethodAttribute : TestMethodAttribute
    {
        public MyTestMethodAttribute([CallerFilePath] string callerFilePath = "", [CallerLineNumber] int callerLineNumber = -1)
        : base(callerFilePath, callerLineNumber)
        {
        }
    }
    
  • Если у вас есть такие приложения атрибутов, как [TestMethodAttribute("Custom display name")], переключите их на [TestMethodAttribute(DisplayName = "Custom display name")].

Tip

Анализатор с Codefix скоро будет доступен, чтобы помочь вам в этой миграции. Один щелчок в интегрированной среде разработки (IDE) исправит все случаи в вашем решении.

Перечисление ClassCleanupBehavior удалено

Теперь методы ClassCleanup выполняются только в конце тестового класса. Поддержка функции очистки класса, которая выполняется в конце сборки, удаляется. Если необходимо выполнить логику очистки после сборки, сделайте это в AssemblyCleanup, а не в ClassCleanup. Поведение очистки класса по умолчанию ранее было "EndOfAssembly", которое пользователи считали ошибкой.

Если у вас ранее был следующий код:

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

Вам потребуется изменить его на следующее:

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

TestContext.Properties теперь является строкой IDictionary<, объект>

Ранее TestContext.Properties был IDictionary. Чтобы обеспечить более эффективное ввод, теперь это IDictionary<string, object>.

Если у вас есть вызовы TestContext.Properties.Contains, обновите их до TestContext.Properties.ContainsKey.

Перечисление TestTimeout удалено

Это перечисление имело только один член, Infinite, значение которого было int.MaxValue. Если у вас есть случаи использования [Timeout(TestTimeout.Infinite)], обновите его до [Timeout(int.MaxValue)].

TestContext.ManagedType теперь удален

Свойство TestContext.ManagedType удаляется. Вместо этого используйте TestContext.FullyQualifiedTestClassName.

Типы, не предназначенные для общедоступного использования, сделаны внутренними или удалены.

  • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod становится внутренним.
    • Обратите внимание, что этот интерфейс отличается от ITestMethod в сборке TestFramework, которая не изменилась.
    • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod не имеет допустимых вариантов использования для пользователей, поэтому оно было сделано внутренне.
  • Некоторые уже устаревшие типы переведены в разряд внутренних. К ним относятся:
    • MSTestDiscoverer
    • MSTestExecutor
    • AssemblyResolver
    • LogMessageListener
    • TestExecutionManager
    • TestMethodInfo
    • TestResultExtensions
    • UnitTestOutcomeExtensions
    • GenericParameterHelper
    • Типы в сборке служб платформы

Изменение сигнатуры API Assert

  • API, которые раньше принимали оба параметра message и object[], теперь принимают только message. Вместо этого используйте интерполяцию строк. Это было необходимое изменение для поддержки выражения аргумента вызывающего объекта для API утверждения.
  • Assert.AreEqual API для IEquatable<T> удалены. Существует очень мало пользователей этого API, и API вводит в заблуждение. Большинство пользователей не затронуты этим удалением, так как API изначально не существовал в MSTest v3 и был представлен в версии 3.2.2.
    • Этот API также вызывает проблемы для пользователей F#. Например, см. fsharp/fslang-suggestions/issues/905.
    • Если это затронет вас, вы получите ошибку компиляции, связанную с выводом обобщенного типа. Все, что необходимо сделать, — явно указать аргумент типа в качестве object.
  • Устаревшие Assert.ThrowsException API удаляются. Анализатор и кодефикс в MSTest 3.10 помогают перенести вас в более новые API.
  • Использования Assert.IsInstanceOfType<T>(x, out var t) теперь должны измениться на var t = Assert.IsInstanceOfType<T>(x).
    • Существующие перегрузки, которые не имели параметра out, изменены так, чтобы возвращать экземпляр типа T вместо void. Это только критическое изменение для F#.

API ExpectedExceptionAttribute удален

Устаревший ExpectedExceptionAttribute API удалён. Анализатор (MSTEST0006) и исправление кода в MSTest 3.2 помогают перейти на Assert.Throws.

Например, если у вас есть следующий код:

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

Вам (или анализатору и исправлению кода) необходимо изменить его следующим образом:

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

Удалены неподдерживаемые целевые фреймворки

Поддержка целевых платформ .NET Core 3.1 до .NET 7 удаляется. Минимальная поддерживаемая версия .NET — .NET 8. Это изменение не влияет на .NET Framework. .NET Framework 4.6.2 по-прежнему является минимальным поддерживаемым целевым объектом .NET Framework.

Стратегия разворачивания перемещена из отдельных источников данных в TestMethodAttribute

Стратегия развертывания — это новая функция, представленная в MSTest 3.7, чтобы обойти известные ограничения. Свойство было добавлено для отдельных источников данных, таких как DataRowAttribute и DynamicDataAttribute. Это свойство было перемещено в TestMethodAttribute.

ConditionBaseAttribute.ShouldRun Изменение API

Свойство ConditionBaseAttribute.ShouldRun было переименовано IsConditionMetв . Это делает более понятным, что ConditionMode не следует использовать в реализации.

Несколько анализаторов обновлены так, чтобы по умолчанию выдавать предупреждения.

Серьезность по умолчанию следующих анализаторов изменилась с Info на Warning:

Изменения, нарушающие поведение

Это критические изменения, которые могут повлиять на поведение во время выполнения.

DisableAppDomain теперь по умолчанию имеет значение true при запуске в Microsoft.Testing.Platform

В версии 4 и при работе с Microsoft.Testing.Platform домены приложений отключены по умолчанию (если они не указаны), так как пользовательская изоляция не используется в большинстве случаев и имеет важное влияние на производительность (до 30% медленнее при выполнении при изоляции).

Однако эта функция остается доступной. Если у вас есть сценарии, требующие этого, добавьте DisableAppDomain параметр в файле runsettings.

Это важно

Если изоляция AppDomain включена, MSTest выгрузит домен приложения после завершения всех тестов, что прерывает все потоки, связанные с Доменом приложения, включая потоки переднего плана. В результате, если у вас есть поток переднего плана, выполняющийся навсегда в MSTest версии 3, тестовый запуск завершится успешно. Тот же сценарий будет зависать в MSTest версии 4, что является оптимальным поведением, так как процесс не должен завершиться, когда поток переднего плана все еще работает.

TestContext вызывает ошибку при неправильном использовании

Тип TestContext передается в AssemblyInitialize, ClassInitialize и тесты, но доступные сведения на каждом этапе отличаются. Исключение выдается при доступе к свойству, связанному с информацией о тестовом запуске в рамках AssemblyInitialize или ClassInitialize.

  • TestContext.FullyQualifiedTestClassName недоступен во время инициализации сборки.
  • TestContext.TestName невозможно получить доступ в фазу инициализации сборки или фазу инициализации класса.

TestCase.Id изменяется

Чтобы устранить долго существующие ошибки, о которых сообщили многие пользователи, была изменена генерация TestCase.Id. Это влияет на функции Azure DevOps, например отслеживание сбоев тестов с течением времени.

По умолчанию значение TreatDiscoveryWarningsAsErrors теперь установлено на True.

Версия 4 использует более строгие значения по умолчанию. Таким образом, значение по умолчанию для TreatDiscoveryWarningsAsErrors теперь — true. Это должно быть прозрачное изменение для большинства пользователей и должно помочь другим пользователям обнаружить скрытые ошибки.

MSTest.Sdk больше не добавляет Microsoft.NET.Test.Sdk ссылку при использовании Microsoft.Testing.Platform

По умолчанию MSTest.Sdk использует Microsoft.Testing.Platform. UseVSTest Если для свойства MSBuild задано значение true, вместо него будет использоваться VSTest. В MSTest 3.x пакет SDK добавил ссылку на Microsoft.NET.Test.Sdk (которая обеспечивает поддержку VSTest) даже при использовании Microsoft.Testing.Platform. Эта ссылка на пакет не требуется при запуске с помощью Microsoft.Testing.Platform и удалена в MSTest версии 4.

Если вы по-прежнему хотите обеспечить поддержку VSTest (например, если вы хотите запустить с помощью vstest.console), необходимо вручную добавить ссылку на пакет Microsoft.NET.Test.Sdk NuGet в проект.