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

101

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

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

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

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

  • Решение с одним проектом C # Unit Test с двумя тестами (один неудачный, один пройденный).
  • Определение сборки XAML с использованием шаблона по умолчанию (TfvcTemplate.12.xaml)
  • Сервер сборки XAML TFS 2015 с обновлением 1 с установленным обновлением 1 Visual Studio Enterprise 2015 (шесть похожих серверов, и все они дают одинаковый результат)
Торе Эстергаард
источник
По словам Брайана Гарри из Microsoft, это ошибка, которую они в настоящее время исследуют. Это должно быть исправлено в обновлении 2, а временное решение должно быть опубликовано позже. Источник: ссылка
Tore Østergaard
У меня такая же проблема для .Net 3.5 SP1 в Visual Studio 2013 Update 5.
Андрей Бушман
@AndreyBushman: Ошибка могла быть и в 2013U5, так как он был выпущен вместе с 2015RTM. Но обходной путь должен работать и в вашем случае.
Tore Østergaard
У меня была аналогичная проблема, обходной путь был просто в vs, в настройках теста, чтобы выбрать правильный бит процессора по умолчанию (32/64) и не поддерживать работу движка. (vs 2017.x)
kfn

Ответы:

2

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

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

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

ПатрикЛу-MSFT
источник
3
Привет, Патрик. Обе предоставленные вами ссылки - это случаи, открытые мной, поэтому я бы не стал доверять им как справочникам ;-).
Tore Østergaard
60

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

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

Скриншот настроек теста

rubeonline
источник
Это решило проблему для меня. В моем случае и тестируемый, и тестовый проект были установлены на x86. Тесты были неприятными, но не прошли. После того, как я изменил его на Any CPU, тесты запустились.
датчан
У меня была такая же проблема, и это решило ее. Мне также весьма подозрительно, что это могло иметь плохой договорно-синергетический эффект на мои основные ссылки на проекты, которые внезапно перестали загружать конкретную DLL, но окончательно не определили этот неприятный побочный эффект.
Аллен
45

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

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

Install-Package NUnitTestAdapter

Как упоминает Морис в комментарии к этому сообщению для NUnit3, используйте следующий пакет NUGET (ищите другие утилиты по ссылке, например: dotnet CLI и Paket CLI)

Install-Package NUnit3TestAdapter

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

Ник Рубино
источник
10
Я тоже сейчас использую VSTS. В соответствии с рекомендациями я добавил NUnit3TestAdapter (поскольку я использую NUnit 3.8.1), и это решение решило мою проблему. Спасибо :-)
Морис Климек
1
Установочный пакет NUnit3TestAdapter решил мою проблему :)
Bimal Das
27

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

  1. Преобразование тестового проекта в netcore 2.0 (было netstandard 2.0)

  2. Добавить пакет nuget xunit.runner.visualstudio

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

уууу
источник
3
такая же проблема была со мной. Я использую xunit с ядром .net
Амна
Это также работало для меня в Visual Studio 2017 с xunit и .NET Core 2.1.
Thorkil Værge
4
в моем случае это был проект .net 4.6.1, поэтому единственное, чего не хватало, - это бегун xunit. Установил и заработало.
Хуан,
1
То же, что и Хуан. Не хватало только раннера. Запуск этого в диспетчере пакетов для тестового проекта решил это: install-package xunit.runner.visualstudio
Premil
12

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

1) Моя папка пакета содержит только пакет MSTest.TestFramework.1.2.1. В моем файле проекта (.csproj) ссылка в Target Name была пакетом MSTest.TestAdapter.1.2.0, которого не было в папке пакета. В моем файле packages.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.

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

квазар
источник
Я столкнулся с этим с .Net 4.6.1 VS2017. Я закончил откат до 1.2.0 - обязательно убедитесь, что у вас нет двух разных версий в папке пакетов или в системе управления версиями.
Джереми Томпсон
2
Казалось, что я нашел тесты, но да, отсутствие «MSTest.TestAdapter» было реальной проблемой. Никаких хороших ошибок или предупреждений (VS2017 15.8). Все выглядело хорошо, за исключением того, что тестов не было найдено, несмотря на то, что они появились в обозревателе тестов ... Итак, когда я сделал "install-package MSTest.TestAdapter", мои тесты неожиданно прошли как ожидалось. Спасибо MS - 3 часа потрачены впустую ...........
Джеймс Джойс
1
Установка MSTest.TestAdapter 1.4.0 сделала это за меня в VS 2019. Благодаря вам я потратил только 30 минут.
furman87
11

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

  1. Я использую Visual Studio Professional 2017
  2. В VS я перешел в Инструменты -> Расширения и обновления.
  3. Вверху меню я заметил, что мой адаптер NUnit отключен.
  4. Я нажал кнопку [Включить]
  5. Я смог запустить тесты без ошибок.
Джей Вуд
источник
Да! И не забудьте перезапустить Visual Studio. Это было необходимо для меня.
Майкл Леви
«Вверху меню» что это значит?
Шон Кендл
1
@SaiyajinGohan. После выполнения шага 2 откроется окно «Расширения и обновления». Вверху этого окна я увидел, что адаптер NUnit отключен. Надеюсь, это проясняет ....
J Wood
Спасибо за это, я все еще не мог заставить это работать с проектом, над которым я работал. К счастью, это был тестовый проект, и следующий сработал. До сих пор остается загадкой, почему.
Шон Кендл
6

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

Один из эффективных способов решения проблемы - удалить удаленный отладчик Microsoft Visual Studio 2017 с затронутого компьютера.

Csapi007
источник
5

Я столкнулся с той же проблемой в VSTS с .Net 4.6.2. Если вы видите это из вывода консоли VSTS, обходной путь, предоставляемый @Sushil, по-прежнему работает в VSTS и необходим. К сожалению, задача «Test Assemblies», предоставленная Microsoft, проходит, так что вы даже не узнаете о проблеме, если не проверите вывод и не обнаружите, что ни один из ваших тестов действительно не выполнен!

Исправление теста VSTS

ратер
источник
Моя проблема заключалась в (локальном) TFS 2015 Update 1, и она была исправлена ​​в обновлении 2. Я не уверен, существует ли такая же проблема с VSTS.
Tore Østergaard
5
  1. Установите последнюю версию Nunit и NUnitTestAdapter из пакета NUGET.
  2. Перейдите в -> Тест -> Настройки теста -> Архитектура процессора по умолчанию -> Перейти на X64
  3. Постройте решение.
  4. Это решит проблему Run Test и Debugger в модульном тестировании, и он начнет работать.
Картикеян Нандагопалан
источник
Это действительно сработало для меня после того, как я ударил головой по всем направлениям и предложениям.
rajibdotnet
4

Если вы запускаете свои тесты внутри докера, используя многоступенчатую сборку, и тесты не найдены. Убедитесь, что вы копируете все файлы, а не только файлы проекта, как показано в разделе 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
Бассам Гамаль
источник
Это действительно меня укусило. Я думаю, что ключ к тому, что это происходит, заключается в том, что он НАХОДИТ DLL модульного теста, но НЕ находит в ней никаких тестов. Я также обнаружил, что размещение этого встроенного кода после ваших операторов копирования позволит вам проверить, что скопировано WAS (здесь / app / tests - ваш целевой каталог в образе Docker): RUN file = "$ (ls -al / app / tests) "&& echo $ file (см. этот пост для получения дополнительной информации об echo )
Дэвид Йейтс
3

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

  1. Удалите ссылки на Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll и расширения.
  2. Установите пакет NuGet Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated.
Ste Brown
источник
3

Убедитесь, что у вас установлен nuget «Microsoft.NET.Test.Sdk».

лордпансар
источник
3

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

n.shojaei
источник
1

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

thatWiseGuy
источник
1

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

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

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

отметка
источник
1

Я получил эту ошибку, потому что мой класс модульного теста не был общедоступным.

Пример:

class ClientTests

Ошибка вывода:

...\bin\Debug\Tests.dll] UTA001: TestClass attribute defined on non-public class ClientTests

Исправление:

public class ClientTests

Джаред Бич
источник
1

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

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

введите описание изображения здесь

jwatts1980
источник
1

Нашел способ! Наверное, не самый ортодоксальный, но очень быстро выручил:

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

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

dave_077
источник
0

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

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

Существует обходной путь описывается @Sushil здесь , который включает добавление .runsettings файла , что силы тест бегун инфраструктуру .NET (пожалуйста , не то, что вы должны указать его в диалоговом окне «Добавить / Изменить Test Run» , как добавить его непосредственно в редакторе процесса сборки игнорируются).

Торе Эстергаард
источник
0

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

Али Юсефи
источник
0

У меня такая же проблема. Я использую Visual Studio 2017 Community Edition.

введите описание изображения здесь

Я использовал эти шаги, чтобы успешно обнаружить все свои тестовые примеры и успешно запустить его:

  • Сначала перейдите в раздел «Расширения и обновления», установите тестовый адаптер NUnit3. Если у вас уже есть, просто включите его.

  • Перезагрузите Visual Studio 2017, он автоматически предложит
    установить расширение. Если появится запрос на завершение задачи, чтобы продолжить
    установку, просто нажмите «Завершить задачу».

  • После этого перестройте свой тестовый проект, и все тестовые примеры будут определены, и теперь вы можете начать выполнение своих тестовых случаев.

Вилли Дэвид младший
источник
0

В моем случае переустановка адаптера Nunit3, удаление временных папок, изменение архитектуры и ничего не помогло. Это из-за того, что Daemon Resharper вызвал проблему.

Add or Remove Programs> Find Resharper > Repair > Install again > Restart VS 

Это решает проблемы.

Рияз Хамид
источник
0

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

пользователь3533716
источник
0

После добавления TestAdapterPath в командир у меня это сработало:

vstest.console.exe Xom.Gci.Lvf.FileParserInvoker.UnitTests.dll /TestAdapterPath:"C:\****\****\{SolutionFolder}"
Диксиаши
источник
Прежде всего, вы должны убедиться, что тестовый пример можно запустить в VS IDE.
dixiashi
0

В моем случае тесты были обнаружены, но их выполнение привело к появлению «Тест недоступен ... » и известному (не) известному: «Убедитесь, что средство обнаружения и исполнители тестов зарегистрированы, а настройки версии платформы и фреймворка соответствуют требованиям и повторите попытку».

ошибка не зависела от Visual Studio (тестировалась с помощью инструментов CLI dotnet и почти голого теста UNit), и это было только при нацеливании на .NET 4.7.1. Приложение dotnetcore работает нормально.

также запуск тестов с помощью интерфейса командной строки Nuint3 nunit3-console.exe Tests.csprojпоказывает ошибку:

«Либо сборка не содержит тестов, либо правильный тестовый драйвер не найден».

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

Фалько Александр
источник
0

Попробуйте запустить vstest.console.exeс --diag:diag.txtи проверьте вывод. Для меня это были сбои загрузки DLL для тестовых адаптеров из моего рабочего каталога:

TpTrace Information: 0 : 14976, 1, 2020/03/10, 15:34:22.120, 57158093583, vstest.console.exe, AssemblyResolver.OnResolve: Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter: Failed to load assembly. Reason:System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Directory\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)

File name: 'file:///C:\Directory\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

Я работал вокруг этого путем добавления в <loadFromRemoteSources enabled="true"/>рамках <runtime>в vstest.console.exe.config

andrew.rockwell
источник
0

Я использую 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 "

ЗеркалоМальчик
источник
0

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

Сурендра Раяпати
источник
0

Я решил эту проблему, установив 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>
Осанда Дешан
источник
0

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

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

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

Тим
источник