Часто задаваемые вопросы о Live Unit Testing

Live Unit Testing работает с тремя популярными платформами модульного тестирования, перечисленными в следующей таблице. Минимальная поддерживаемая версия их адаптеров и платформ также указана в таблице. Платформы модульного тестирования доступны в NuGet.org.

Если у вас есть старые тестовые проекты на основе MSTest, ссылающиеся на Microsoft.VisualStudio.QualityTools.UnitTestFramework, и вы не хотите переходить к новым пакетам NUGet MSTest, обновите до Visual Studio 2019 или Visual Studio 2017.

Да. Live Unit Testing работает с .NET Core и .NET Framework.

Окно вывода (при выборе раскрывающегося списка Live Unit Testing) должно сообщить, почему Live Unit Testing не работает. Динамическое модульное тестирование может не работать по одной из следующих причин:

• Если пакеты NuGet, на которые ссылается проекты в решении, не были восстановлены, Live Unit Testing не будет работать. Выполнение явной сборки решения или восстановление пакетов NuGet в решении перед включением Live Unit Testing должно устранить эту проблему.

• Если вы используете тесты на основе MSTest в проектах, удалите ссылку на Microsoft.VisualStudio.QualityTools.UnitTestFrameworkи добавьте ссылки на последние пакеты NuGet MSTest, MSTest.TestAdapter (минимальная версия 1.1.11 требуется) и MSTest.TestFramework (минимальная версия 1.1.11 требуется). Дополнительные сведения см. в разделе "Поддерживаемые платформы тестирования" статьи Использование Live Unit Testing в Visual Studio.

• По крайней мере один проект в решении должен иметь ссылку На NuGet или прямую ссылку на платформу тестов xUnit, NUnit или MSTest. Этот проект также должен ссылаться на соответствующий пакет NuGet для тестовых адаптеров Visual Studio.

Ошибки сборки отображаются в окне вывода при выборе раскрывающегося списка Live Unit Testing. Существует несколько распространенных проблем, вызванных неправильной конфигурацией в мастере установки , которые могут привести к проблемам сборки в Live Unit Testing.

• Если свойство корневого рабочей области слишком длинно, возможно, что сборка завершится ошибкой из-за исключений, указывающих, что путь слишком длинный.

• Если свойство корневого репозитория репозитория не указывает на корневой каталог репозитория, рабочая область будет заполнена неправильным набором файлов.

• Для репозиториев Git исключить файлы обычно избегает копирования файлов, указанных в файле gitignore. Однако можно проверить файлы в репозитории Git, которые игнорируются, или запустить средства, которые автоматически создают файлы, но они не создаются во время сборки. В таких случаях следует выбрать параметр "<настраиваемых>" и настраиваемый набор правил, в который должны быть перечислены только папки артефактов.

Помимо описанных ранее проблем, приведенные ниже конфигурации проекта, которые могут не создаваться правильно.

• Если зависимости проекта указаны как глобальная конфигурация решения, а не как ProjectReferences для каждого проекта, Live Unit Testing может в конечном итоге создать неправильный набор проектов. Чтобы устранить эту проблему, добавьте явные ссылки между проектами.

• Пока список воспроизведения Live Unit Testing не будет выбран, Live Unit Testing не будет создавать проекты. Чтобы устранить эту проблему, включите некоторые тесты в список воспроизведения Live Unit Testing.

• Если вы используете тесты на основе MSTest в проектах, удалите ссылку на Microsoft.VisualStudio.QualityTools.UnitTestFrameworkи добавьте ссылки на последние пакеты NuGet MSTest, MSTest.TestAdapter (минимальная версия 1.1.11 требуется) и MSTest.TestFramework (минимальная версия 1.1.11 требуется). Дополнительные сведения см. в разделе Поддерживаемые платформы тестирования.

• По крайней мере один проект в решении должен иметь ссылку На NuGet или прямую ссылку на платформу тестов xUnit, NUnit или MSTest. Этот проект также должен ссылаться на соответствующий пакет NuGet для тестовых адаптеров Visual Studio. Также можно ссылаться на адаптер тестирования Visual Studio с помощью файла .runsettings. Файл .runsettings должен иметь запись, как показано в следующем примере:

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

Live Unit Testing не может создавать проекты исходного генератора с инструментированием. Из-за того, как компилятор C# настраивает загрузку сборок для исходных генераторов, попытка создания проектов генератора источников с инструментированием не загружает сборки Live Unit Testing.

Вы можете задать свойство <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> в файлах csproj исходного генератора, чтобы создать эти проекты в Live Unit Testing.

Live Unit Testing запускает сборку внутри собственного процесса по соображениям производительности. Если этот отдельный процесс сборки вызывает ошибку, можно задать <UseInProcMSBuildNode>false</UseInProcMSBuildNode> в файл .lutconfig, чтобы убедиться, что все сборки выполняются в процессе MSBuild.

• Распространенная проблема заключается в том, что не все файлы копируются в тестовую папку. Возможно, потребуется добавить некоторые элементы зависимостей Live Unit Testing в файлы cspro j csproj.

• Другая проблема заключается в истечении времени ожидания. Так как Live Unit Testing выполняет тесты неограниченное время, он автоматически прерывает выполнение, если тесты выполняются слишком долго. Вы можете увеличить время ожидания в мастере проекта.

• Если несколько проектов в решении ссылаются на пакет тестового адаптера NuGet, каждый из них должен быть обновлен до поддерживаемой версии.

• Убедитесь, что файл MSBuild .props, импортированный из пакета адаптера тестирования, правильно обновляется. Проверьте версию пакета NuGet или путь к импорту, которая обычно находится в верхней части файла проекта, как показано ниже.

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Если для решения требуются пользовательские шаги для создания инструментирования (Live Unit Testing), которые не требуются для обычной не инструментируемой сборки, вы можете добавить код в проект или .targets файлы, которые проверяют свойство BuildingForLiveUnitTesting и выполняют пользовательские действия перед сборкой. Вы также можете удалить определенные шаги сборки (например, публикацию или создание пакетов) или добавить шаги сборки (например, необходимые для копирования) в сборку Live Unit Testing на основе этого свойства проекта. Настройка сборки на основе этого свойства не изменяет обычную сборку в любом случае и влияет только на сборки Live Unit Testing.

Например, во время обычной сборки может быть целевой объект, который создает пакеты NuGet. Возможно, вам не нужно создавать пакеты NuGet после каждого изменения. Таким образом, вы можете отключить этот целевой объект в сборке Live Unit Testing, выполнив следующее:

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' != 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

Существует несколько различий:

• Выполнение или отладка тестов из обозревателя тестов запускает обычные двоичные файлы, в то время как Live Unit Testing запускает инструментированные двоичные файлы. Если вы хотите выполнить отладку инструментированных двоичных файлов, добавление вызова метода Debuger.Launch в методе теста приводит к тому, что отладчик запускается всякий раз, когда этот метод выполняется (в том числе при выполнении Live Unit Testing), а затем можно подключить и выполнить отладку инструментированного двоичного файла. Однако мы надеемся, что инструментирование прозрачно для большинства пользовательских сценариев и что не нужно отлаживать инструментированные двоичные файлы.

• Live Unit Testing не создает новый домен приложения для выполнения тестов, но тесты, выполняемые из обозревателя тестов, создают новый домен приложения.

• Live Unit Testing выполняет тесты в каждой тестовой сборке последовательно. В обозревателе тестовможно параллельно запускать несколько тестов.

• обозреватель тестов выполняет тесты в однопоточной квартире (STA), в то время как Live Unit Testing выполняет тесты в многопоточной квартире (MTA). Чтобы запустить тесты MSTest в STA в Live Unit Testing, украсите метод теста или содержащий класс с помощью атрибута <STATestMethod> или <STATestClass>, который можно найти в пакете NuGet MSTest.STAExtensions 1.0.3-beta. Для NUnit украсите метод теста атрибутом <RequiresThread(ApartmentState.STA)> и xUnit с атрибутом <STAFact>.

Дополнительные сведения см. в разделе "Включение и исключение тестовых проектов и методов тестирования" статьи Использование Live Unit Testing в Visual Studio. Включение или исключение тестов полезно при выполнении определенного набора тестов для определенного сеанса редактирования или сохранения собственных личных предпочтений.

Для параметров, относящихся к решению, можно применить атрибут System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute программным способом, чтобы исключить методы, свойства, классы или структуры из инструментирования с помощью Live Unit Testing. Кроме того, можно также задать для свойства <ExcludeFromCodeCoverage> значение true в файле проекта, чтобы исключить инструментирование всего проекта. Live Unit Testing по-прежнему будет запускать тесты, которые не были инструментированы, но их покрытие не будет визуализировано.

Вы также можете проверить, загружается ли Microsoft.CodeAnalysis.LiveUnitTesting.Runtime в текущем домене приложения и отключать тесты на основе причин. Например, можно сделать следующее с помощью xUnit:

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

Решение может создаваться, даже если вы не вносите изменения, если процесс сборки создает исходный код, который является частью самого решения, и целевые файлы сборки не имеют соответствующих входных и выходных данных. Целевые объекты должны быть указаны в списке входных и выходных данных, чтобы MSBuild могли выполнять соответствующие проверки up-to-date и определить, требуется ли новая сборка.

Live Unit Testing запускает сборку всякий раз, когда обнаруживает, что исходные файлы изменились. Так как сборка решения создает исходные файлы, Live Unit Testing переходит в бесконечный цикл сборки. Однако если входные и выходные данные целевого объекта проверяются, когда Live Unit Testing запускает вторую сборку (после обнаружения недавно созданных исходных файлов из предыдущей сборки), она прерывается из цикла сборки, так как входные и выходные данные указывают на то, что все up-to-date.

В редакторе могут не отображаться значки, если сборки, на которых работает Live Unit Testing, не инструментируются по какой-либо причине. Например, Live Unit Testing несовместим с проектами, которые задают <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. В этом случае процесс сборки необходимо обновить, чтобы удалить этот параметр или изменить его на true для работы Live Unit Testing. 

Для сбора более подробных журналов можно выполнить несколько действий.

• Перейдите в раздел Средства>параметры>Live Unit Testing и измените параметр ведения журнала на Подробные. Подробное ведение журнала приводит к отображению более подробных журналов в окне выходных данных.

• Задайте для переменной пользовательской среды LiveUnitTesting_BuildLog имя файла, который вы хотите использовать для записи журнала MSBuild. Подробные сообщения журнала MSBuild из сборок Live Unit Testing можно получить из этого файла.

• Задайте для переменной пользовательской среды LiveUnitTesting_TestPlatformLog значение 1 для записи журнала тестовой платформы. Подробные сообщения журнала платформы тестирования из запуска Live Unit Testing можно получить из [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID].

• Создайте переменную среды уровня пользователя с именем VS_UTE_DIAGNOSTICS и задайте для нее значение 1 (или любое значение) и перезапустите Visual Studio. Теперь на вкладке "Тесты" в Visual Studio должно появиться много ведения журнала.

Нет, не следует открывать или изменять файлы в каталогах сборки и тестирования папки рабочей области. Live Unit Testing должен управлять всеми файлами в папке src, чтобы сохранить их в синхронизации между корневой репозитория и корневой рабочей области корневой.

Да, но необходимо убедиться, что он включен. Если вы используете диск разработки, убедитесь, что проецируемых файловых систем (ProjFS) включен фильтр. Например, следующая команда включает ProjFS и Защитник Windows:

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

См. также

• Live Unit Testing