Не удается запустить тесты XUnit с .NET Core

Я переношу небольшую библиотеку, которая у меня на NuGet, на .NET Core.

Я создал библиотеки классов .NET Standard 1.6 для основного проекта и тестов и скопировал код. Я изменил модульные тесты, чтобы использовать атрибуты XUnit и утверждает, а не NUnit.

Кроме того, я в значительной степени следовал инструкциям в документации, поэтому я добавил следующие пакеты NuGet:

Microsoft.NET.Test.Sdk
XUnit
xunit.runner.visualstudio

Увы, 1) Test Explorer не находит мои модульные тесты и (2) когда я запускаю dotnet test, я получаю следующее:

Запуск тестового исполнения, пожалуйста, подождите... Не удалось найти testhost.dll для источника '[...]. Tests.dll'. Убедитесь, что в тестовом проекте есть ссылка на nuget пакета "microsoft.testplatform.testhost".

Я действительно добавил предложенный пакет Microsoft.TestPlatform.TestHost NuGet, но ничего не изменил.

Итак, в чем проблема?

Я использую VS2017. Не то чтобы я думаю, что это имеет значение.

Обновить: изменение тестового проекта с Class Library (.NET Standard) до Class Library (.NET Core) устраняет проблему. Я до сих пор не понимаю, почему это должно иметь значение.

Ответ 1

Изменение тестового проекта с библиотеки классов (.NET Standard) на библиотеку классов (.NET Core) решило проблему. Я до сих пор не понимаю, почему это должно иметь значение.

Модульные тесты - это приложения, которые мы запускаем. Чтобы построить такое приложение, мы должны указать среду выполнения и модель приложения. Когда мы ориентируемся на .NET Standard, среда выполнения и модель приложения неоднозначны; MSBuild не знает, следует ли выполнять сборку на основе .NET Framework,.NET Core, Mono/Xamarin или другой платформы, соответствующей стандарту .NET. Таргетинг .NET Core предоставляет необходимые данные для MSBuild, который теперь знает, как разрешить все упомянутые сборки/проекты и выбрать соответствующую версию платформы.

Но это никогда не было так. В прошлом вы всегда использовали библиотеку классов для модульных тестов; это никогда не считалось приложением, которое вы могли бы запустить, а скорее набором классов и методов, которые вы могли бы передать тестирующему.

В прошлом у нас не было .NET Standard, что является неоднозначной целью. Когда MSBuild видит .NET Standard, ему нужно больше информации. "Хорошо, какую среду выполнения, совместимую со стандартом .NET, вы хотите использовать для создания работоспособного вывода?" Если, например, мы нацелены на netstandard1.2, то MSBuild не будет знать, следует ли выполнять сборку на основе .NET Core 1.0,.NET Framework 4.5.1, Windows 8.1 или нескольких других netstandard1.2 совместимых платформ.

При запуске теста, пожалуйста, подождите... Не удалось найти testhost.dll для источника '[...]. Tests.dll'. Убедитесь, что в тестовом проекте есть ссылка на nuget из пакета "microsoft.testplatform.testhost".

Если мы не укажем netcoreapp, то MSBuild предполагает, что мы используем полную структуру. В этом случае ожидается, что целевые сборки, включая testhost.dll, будут в bin. Если это не так (и не будет, если мы построили против .NET Standard), мы получим вышеуказанную ошибку.