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

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

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

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

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

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

Ответы

Ответ 1

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

Подробнее и обходной путь - pl ссылку здесь

Ответ 2

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

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

Screenshot of test settings

Ответ 3

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

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

VSTS Test Fix

Ответ 9

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

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

Ответ 10

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

enter image description here

Ответ 16

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

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

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

Ответ 17

Это только для того, чтобы повторить решение, ранее отправленное @Sushil.

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

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

Ответ 18

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

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

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

Ответ 19

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

Ответ 20

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

Пример:

class ClientTests

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

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

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

public class ClientTests

Ответ 21

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

Ответ 22

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

enter image description here

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

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

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

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

Ответ 23

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

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

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

Ответ 24

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

Ответ 25

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

vstest.console.exe Xom.Gci.Lvf.FileParserInvoker.UnitTests.dll /TestAdapterPath:"C:\****\****\{SolutionFolder}"

Ответ 26

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

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

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

"Либо сборка не содержит тестов, либо подходящий тестовый драйвер не найден".

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

Ответ 27

Если вы выполняете свои тесты в докере с использованием многоэтапного построения и тесты не найдены. Убедитесь, что вы скопировали все файлы, а не только файлы проекта, как показано ниже в разделе 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