Часто задаваемые вопросы о функции 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 свойство Exclude files обычно избегает копирования файлов, указанных в файле gitignore . Однако в репозитории Git можно выполнить проверку файлов, которые игнорируются или можно запускать средства, которые автоматически создают файлы, но они не создаются во время сборки. В этих случаях следует выбрать параметр "Custom>",< а также настраиваемый набор правил, в который должны быть перечислены только папки артефактов.

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

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

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

• Если вы используете тесты на основе MSTest в проектах, удалите ссылку Microsoft.VisualStudio.QualityTools.UnitTestFrameworkи добавьте ссылки на последние пакеты MSTest.TestAdapter NuGet MSTest (минимальная версия 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 в файлы csproj .

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

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

• Убедитесь, что PROPS-файл MSBuild, импортированный из пакета адаптера теста, также обновлен должным образом. Проверьте версию и путь импорта для пакета 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), которые не требуются для обычной сборки, не инструментируемой сборки, можно добавить код в проект или целевые файлы, которые проверяют 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 — инструментированные двоичные файлы. Если вы хотите выполнить отладку инструментированных двоичных файлов, добавьте вызов метода Debugger.Launch в метод теста. После этого отладчик будет запускаться во время каждого выполнения метода (в том числе когда этот метод выполняется с помощью функции Live Unit Testing), и тогда вы сможете прикрепить инструментированные двоичные файлы, а также выполнить их отладку. Однако мы надеемся, что инструментирование прозрачно для большинства пользовательских сценариев и что не нужно отлаживать инструментированные двоичные файлы.

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

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

• Обозреватель тестов по умолчанию выполняет тесты в однопотоковом подразделении (STA), а Live Unit Testing — в многопотоковом (MTA). Чтобы выполнить тесты MSTest в однопотоковом подразделении с помощью функции Live Unit Testing, декорируйте метод теста или содержащий класс атрибутом <STATestMethod> или <STATestClass>, который находится в пакете MSTest.STAExtensions 1.0.3-beta NuGet. Для 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 сможет выполнять соответствующие проверки наличия обновлений и определять, требуются ли они для новой сборки.

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

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

Чтобы собрать более подробные журналы, выполните следующее:

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

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

• Задайте для пользовательской переменной среды LiveUnitTesting_TestPlatformLog значение 1, чтобы собирать журнал тестовой платформы. Теперь в файле [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

См. также

• Динамическое модульное тестирование