Тест не найден. Убедитесь, что установленные тестовые первооткрыватели и исполнители, настройки версии платформы и фреймворка соответствуют требованиям и повторите попытку.

Question

Я нахожусь в процессе обновления нашего существующего решения до.Net 4.6.1 и не смог запустить наши модульные тесты во время сборки сервера. Локально они работают как положено, и переключение версии фреймворка обратно на.Net 4.5.1 заставляет их снова запускаться на сервере.

Я получаю следующую ошибку:

Тест не найден. Убедитесь, что установленные тестовые первооткрыватели и исполнители, настройки версии платформы и платформы соответствуют требованиям и повторите попытку.

Я воспроизвел проблему в более простой настройке:

• Решение с одним C# модульным тестовым проектом с двумя тестами (один провал, один прохождение).
• Определение сборки XAML с использованием шаблона по умолчанию (TfvcTemplate.12.xaml)
• TFS 2015 Update 1 Сервер сборки XAML с установленным Visual Studio Enterprise 2015 Update 1 (имеет шесть одинаковых серверов, и все они дают одинаковый результат)

Answer 1

Это известная проблема, решаемая в VS 2015 Update 2.

Для деталей и обходного пути - пожалуйста, обратитесь сюда

Answer 2

Вы можете попробовать изменить архитектуру процессора по умолчанию в настройках теста с X86 на X64. В моем случае это была проблема.

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

Answer 3

Моя сборка тоже не нашла тестов. Моя настройка и решение для поиска тестов заключаются в следующем.

Я использую VSTS (Visual Studio Team Services) и имею сборку, настроенную для обновления пакетов NUGET в каждой сборке. Я использую NUnit и обнаружил, что при выполнении следующей команды NUGET (из консоли диспетчера пакетов в Visual Studio), чтобы добавить библиотеку NUnitTestAdapter в мой тестовый проект, и проверка в файле packages.config заставила выполнить тесты в моей сборке VSTS.

Install-Package NUnitTestAdapter

Как упоминает Морис в комментарии к этому сообщению для NUnit3, используйте следующий пакет NUGET

Install-Package NUnit3TestAdapter

Надеюсь это поможет.

Answer 4

В моем случае пришлось:

1) конвертировать тестовый проект в netcore 2.0 (был netstandard 2.0)

2) добавить пакет Nuget xunit.runner.visualstudio

Ссылка: http://www.neekgreen.com/2017/11/20/xunit-no-test-is-available/

Answer 5

Я использую MSTest. Для меня это было несоответствие версий и отсутствие другого зависимого пакета-

1) Моя папка содержит только пакет MSTest.TestFramework.1.2.1. В моем файле проекта (.csproj) ссылка в Target Name была пакетом MSTest.TestAdapter.1.2.0, которого не было в папке пакета. В моем package.config также есть ссылка на MSTest.TestFramework.1.2.0.

2) Поэтому я установил MSTest.TestAdapter.1.2.0 из диспетчера пакетов nuget и совместил версию MSTest.TestFramework с 1.2.0 в файле проекта и пакета. Наконец, я добавляю в ссылку Microsoft.VisualStudio.TestPlatform.TestFramework и Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions.

Тогда все было в порядке. Надеюсь, это поможет кому-то.

Answer 6

Я получил эту ошибку и смог ее устранить.

1. Я использую Visual Studio Professional 2017
2. В VS я перешел в Инструменты -> Расширения и обновления
3. В верхней части меню я заметил, что мой адаптер NUnit был отключен
4. Я нажал кнопку [Включить]
5. Я смог начать тесты без ошибок.

Answer 7

Я исправил эту проблему, переустановив все связанные с тестированием пакеты NuGet для проекта: Xunit, Xunit.runner.vistualstudio, Microsoft.Net.Test.Sdk

Answer 8

1. Установите последнюю версию Nunit и NUnitTestAdapter из пакета NUGET.
2. Перейдите в ----> Test -----> Test Settings ---> Архитектура процессора по умолчанию ------> Изменить на X64
3. Постройте решение.
4. Это решит проблему Run Test и Debugger в модульном тестировании, и он начнет работать.

Answer 9

Эта проблема снова появляется для Visual Studio 2017. Скорее всего, еще одна ошибка, но тот же результат.

Один из обходных путей, который, кажется, работает, - это удалить Microsoft Visual Studio 2017 Remote Debugger с уязвимой машины.

Answer 10

Я брошу свое решение в кучу. В моем случае я добавляю пару проектов к существующему решению вместе с тестовыми проектами для них. Мы используем MSTest. В решении, которое вызывало проблемы совместимости, был включен предыдущий файл UnitTest.testsettings.

Нажатие на файл настроек убрало проверку, и тестовый прогон прошел успешно для моих тестов.

Answer 11

Я столкнулся с той же проблемой в VSTS с.Net 4.6.2. Если вы видите это из вывода консоли VSTS, обходной путь, предоставленный @Sushil, все еще работает в VSTS и необходим. К сожалению, задача "Сборки тестов", предоставленная Microsoft, проходит, так что вы действительно даже не знаете, что есть проблема, если вы не проверили вывод и не нашли ни одного из ваших тестов, которые фактически выполнялись!

Answer 12

С помощью net6.0 targetFramework я добавил эти пакеты в файл .csproj:

      <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.10.0" />
<PackageReference Include="MSTest.TestAdapter" Version="2.2.5" />
<PackageReference Include="MSTest.TestFramework" Version="2.2.5" />

после чего он начал работать. более ранние версии могут быть несовместимы с net6.0.

Answer 13

Я столкнулся с подобной проблемой, когда попробовал nUnit в VS 2017, и это не основной проект. Установка NUnit3TestAdapter устранила проблему.

Answer 14

я установил nunit3adapterpackage, и это сработало для меня из моего журнала испытаний:
-->(NUnit3TestExecutor discovered 6 of 6 NUnit test cases using Current Discovery mode, Non-Explicit run)

Answer 15

Этот вопрос, очевидно, задают люди с различными сценариями, мой ответ будет касаться запуска тестов XUnit в проекте .NET Core с использованием конвейера сборки в Azure DevOps, но может помочь и другим.

• Убедитесь, что у вас установлены тестовые адаптеры XUnit из nuget в соответствии с этим ответом.
• В yaml для конвейера сборки добавьте otherConsoleOptions: '/framework:.NETCoreApp,Version=v3.1' к inputs вашей VSTest@2step (с номером версии, установленным для той версии.NET Core, которую вы используете). См. Эту документацию для получения дополнительной информации.
• Хотя это не обязательно, я бы также рекомендовал добавить failOnMinTestsNotRun: true так что конвейер сборки сообщит об ошибке, если не будут запущены нулевые тесты.
• Если вы запустите сборку на этом этапе, вы можете обнаружить, что ваши тесты выполняются, но конвейер затем выдает ошибку The library 'hostpolicy.dll' required to execute the application was not found. Вы можете решить эту проблему, изменив свой фильтр по умолчанию **\*test*.dllк **\*test.dll(обратите внимание на удаленную звездочку) или какой-либо другой шаблон, который будет соответствовать DLL вашего тестового проекта. Причина в том, что XUnit размещает файл с именем testhost.dllв выходном каталоге, как описано в этой проблеме на github.

Если вы используете старые конвейеры, которые не используют yaml, должны быть доступны те же параметры. В этом ответе рассматривается добавление фреймворка. Я предполагаю, что также будет возможность "Не выполнить задачу, если не выполнено минимальное количество тестов" или что-то подобное.

Answer 16

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

FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS build
WORKDIR /src
COPY ["MainProject/FirstApp.csproj", "MainProject/"]
COPY ["TestProject/*", "TestProject/"]

RUN dotnet restore "TestProject/TestProject.csproj"
RUN dotnet build "TestProject/TestProject.csproj" -c Release
RUN dotnet test "TestProject/TestProject.csproj" -c Release

Answer 17

Я решил эту проблему, установив NUnit3TestAdapter NuGet в свой проект (https://www.nuget.org/packages/NUnit3TestAdapter/).

dotnet add package NUnit3TestAdapter --version 3.17.0

Мой файл .csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.7.1" />
    <PackageReference Include="NUnit" Version="3.12.0" />
    <PackageReference Include="NUnit3TestAdapter" Version="3.17.0" />
    <PackageReference Include="RestSharp" Version="106.11.7" />
  </ItemGroup>

</Project>

Answer 18

Убедитесь, что у вас установлен nuge t "Microsoft.NET.Test.Sdk".

Answer 19

Используя.Net Core с конвейером сборки в TFS 2017, мой шаг по тестированию Visual Studio прошел без фактического выполнения каких-либо тестов. Пришлось отредактировать шаг "Дополнительные параметры выполнения" -> "Другие параметры консоли", включив в него:

/framework:".NETCoreApp,Version=v2.0"

(Это поле также содержит /platform:x64)

Answer 20

Я исправил эту проблему в тестовом проекте VS 2017 и 4.6.2, выполнив следующие действия:

1. Удалите ссылки на Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll и расширения
2. Установите пакет обновления Microsoft.VisualStudio.QualityTools.UnitTestFramework.Udated.

Answer 21

Я использую MSTest.

Я установил из Nuget последнюю версию MSTest.TestFramework и заменил OOB Удалить ссылки на Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

Затем установили из neget последнюю версию Microsoft.TestPlatform

Это позволило мне запустить тест с помощью команды:

".\packages\Microsoft.TestPlatform.16.6.1\tools\net451\Common7\IDE\Extensions\TestPlatform\vstest.console.exe" "UnitTestProject1\bin\Debug\UnitTestProject1.dll" /logger:trx

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

Решение:

1. Установите пакет nuget "MSTest.TestAdapter"

2. В конце команды укажите тестовый адаптер:

   /TestAdapterPath:".\packages\MSTest.TestAdapter.2.1.2\build_common "

Answer 22

Это известная проблема для.Net 4.6 сейчас.

Невозможно запустить модульные тесты.Net 4.6.x в составе сборки XAML TFS с TFS 2015 UPdate1. Источник: https://connect.microsoft.com/VisualStudio/feedback/details/2245723

Вот аналогичный вопрос, к которому вы можете обратиться: Невозможно запустить.Net 4.6 Модульные тесты сервера сборки TAM 2015 XAML

Answer 23

Я только что рассмотрел эту проблему. Кажется, причин для этого может быть много. В моем случае я пробовал несколько кодов, и из-за этого я переименовал проект, удалил его ... добавил его снова ... и внезапно мой единственный тест перестал работать, и в окне вывода теста отображалась эта ошибка: «Тест не найден. Убедитесь, что установленные средства обнаружения и исполнители тестов, настройки платформы и версии фреймворка соответствуют требованиям, и попробуйте еще раз» В выходных данных отладки были показаны ошибки, связанные с платформой: «Следующие библиотеки DLL не соответствуют текущим настройкам, которые являются .netframework, версия 4.5 и платформа X86 ».

Использование VS 2019 v 16.8.0 Тестовый проект на .NET Framework 4.8, настроенный для отладки / любого процессора

Попробовав кучу вещей, решение было

• Закройте Visual Studio
• Переименуйте папку, в которой находится ваше решение. Например: C:\Git\ Решение для C:\Git\Solution2
• Откройте VS и загрузите свое решение. Попробуйте запустить тест.

Это сработало для меня, надеюсь, это сработает для вас.

Answer 24

Эта ошибка может произойти для асинхронных тестов, если у вас неправильный тип возврата. Тип возвращаемого значения должен быть Task, а не void.

Answer 25

Еще одна случайная вещь, которую нужно сделать, это добавить файлxunit.runner.json.

Пример конфигурации:

      {
  "$schema": "https://xunit.net/schema/current/xunit.runner.schema.json",
  "appDomain": "ifAvailable",
  "shadowCopy": false,
  "parallelizeTestCollections": false,
  "maxParallelThreads": 1
}

Не забудьте включить его в проект:

      <ItemGroup>
  <Content Include="xunit.runner.json" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

В моем случае это было волшебное средство.

Answer 26

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

Недавно я написал несколько модулей F#, которые (по некоторым причинам) имеют файлы сигнатур . Опять же, по причинам, мне пришлось поместить модульные тесты в один и тот же модуль.

Когда исходный файл F# «покрывается» файлом подписи, экспортируются только объявленные значения. Таким образом, вы также должны явно объявлять каждый тест в файле подписи, иначе вы получите сообщение об ошибке в OP.

Answer 27

В Visual Studio 2017 я просто удаляю и переустанавливаю NUnitTestAdapter или устанавливаю новый пакет, такой как NUnitTestAdapter.WithFramework, и проблема устранена.

Answer 28

Я получал похожую проблему и заметил, как-то app.config файл был добавлен в мой тестовый проект. Удаление этого файла конфигурации исправило это для меня.

Answer 29

Это просто повторение решения, предложенного @Sushil ранее.

Это известная проблема в Team Foundation Server 2015 RTM + обновление 1, которая будет исправлена ​​в обновлении 2, ссылка.

Здесь есть обходной путь, описанный @Sushil, который включает добавление файла.runsettings, который принудительно запускает тестировщика в более старую платформу.Net (пожалуйста, не нужно указывать его в диалоговом окне "Добавить / редактировать тестовый прогон", так как вы добавляете его напрямую в процессе сборки редактор будет игнорироваться).

Answer 30

Нашел способ! Вероятно, не самый ортодоксальный, но это помогло мне в спешке:

1. Обновите пакеты MSTest.TestAdapter и MSTest.TestAdapterFramework до версии 1.4.0, выбрав Инструменты> Диспетчер пакетов NuGet.
2. Очистите раствор и снова запустите тесты.

Я не думаю, что это что-то особенное с версией, но ее обновление, безусловно, удаляет все плохие ссылки в решении / проекте.