Ответ 1
Это известная проблема, которая рассматривается в обновлении версии VS 2015 2.
Подробнее и обходной путь - pl ссылку здесь
Я занимаюсь модернизацией существующего решения .Net 4.6.1 и не смог выполнить наши модульные тесты во время сборки сервера. Локально они запускаются, как ожидалось, и переворачивают версию фреймворка обратно .Net 4.5.1 заставляет их снова запускаться на сервере.
Я получаю следующую ошибку:
Не найдено ни одного теста. Убедитесь, что установленные испытатели и исполнители, настройки платформы и платформы версии являются подходящими и повторите попытку.
Я воспроизвел проблему в более простой настройке:
Это известная проблема, которая рассматривается в обновлении версии VS 2015 2.
Подробнее и обходной путь - pl ссылку здесь
Вы можете попробовать изменить архитектуру процессора по умолчанию в настройках теста с X86 на X64. В моем случае это была проблема.
Это происходит, если для платформы тестируемого проекта установлено значение x64
.
Моя сборка тоже не нашла тестов. Моя настройка и решение для поиска тестов заключаются в следующем.
Я использую 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
Надеюсь это поможет.
В моем случае пришлось:
1) конвертировать тестовый проект в netcore 2.0 (был netstandard 2.0)
2) добавить пакет xunit.runner.visualstudio
Ссылка: http://www.neekgreen.com/2017/11/20/xunit-no-test-is-available/
Я получил эту ошибку и смог ее устранить.
Я использую 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.
Тогда все было в порядке. Надеюсь, это поможет кому-то.
Эта проблема снова появляется для Visual Studio 2017. Скорее всего, еще одна ошибка, но тот же результат.
Один из обходных путей, который, кажется, работает, - это удалить Microsoft Visual Studio 2017 Remote Debugger с уязвимой машины.
Я столкнулся с той же проблемой в VSTS с .Net 4.6.2. Если вы видите это на своем выходе консоли VSTS, обходной путь, предоставляемый @Sushil, по-прежнему работает в VSTS и необходим. К сожалению, задача "Test Assemblies", предоставляемая Microsoft, проходит, поэтому вы действительно даже не знаете, что есть проблема, если вы не проверите вывод и не найдете ни одного из выполненных тестов!
Я исправил эту проблему в тестовом проекте VS 2017 и 4.6.2, выполнив следующие действия:
Это известная проблема для .Net 4.6.
Невозможно запустить .NET-тесты 4.6.x как часть сборки XAML TFS с TFS 2015 UPdate1 Источник: https://connect.microsoft.com/VisualStudio/feedback/details/2245723
Вот аналогичный вопрос для вас: Невозможно запустить .Net 4.6 Модульные тесты сервера сборки XFSL TFS 2015
Убедитесь, что у вас установлен nuget "Microsoft.NET.Test.Sdk".
У меня была похожая проблема, и я заметил, что файл app.config
был добавлен в мой тестовый проект. Удаление этого файла конфигурации исправило это для меня.
Я исправил эту проблему, переустановив все связанные с тестированием пакеты NuGet для проекта: Xunit, Xunit.runner.vistualstudio, Microsoft.Net.Test.Sdk
Я брошу свое решение в кучу. В моем случае я добавляю пару проектов к существующему решению вместе с тестовыми проектами для них. Мы используем MSTest. В решении, которое вызывало проблемы совместимости, был включен предыдущий файл UnitTest.testsettings.
Нажатие на файл настроек убрало проверку, и тестовый запуск был успешным для моих тестов.
Нашел способ! Вероятно, не самый ортодоксальный, но это помогло мне в спешке:
Я не думаю, что это что-то особенное с версией, но ее обновление, безусловно, удаляет все плохие ссылки в решении/проекте.
Это только для того, чтобы повторить решение, ранее отправленное @Sushil.
Это известная проблема в Team Foundation Server 2015 RTM + Update 1 и будет исправлена в обновлении 2, ссылка.
Существует обходное решение, описанное @Sushil здесь, которое включает в себя добавление файла .runsettings, который заставляет тестовый бегун старше .Net framework ( не нужно указывать его в диалоговом окне "Добавить/редактировать тестовый прогон", так как его добавление непосредственно в редакторе процесса сборки будет проигнорировано).
Используя .Net Core с конвейером сборки в TFS 2017, мой шаг по тестированию Visual Studio прошел без фактического выполнения каких-либо тестов. Пришлось отредактировать шаг "Дополнительные параметры выполнения" → "Другие параметры консоли", включив в него:
/framework:".NETCoreApp,Version=v2.0"
(Это поле также содержит /platform:x64
)
В Visual Studio 2017 я просто удаляю и переустанавливаю NUnitTestAdapter или устанавливаю новый пакет, такой как NUnitTestAdapter.WithFramework, и проблема устранена.
Я получил эту ошибку, потому что мой класс модульного теста не был общедоступным.
Пример:
class ClientTests
Ошибка в выводе:
...\bin\Debug\Tests.dll] UTA001: TestClass attribute defined on non-public class ClientTests
Исправление:
public class ClientTests
Я сталкивался с подобной проблемой, когда пытался nUnit в VS 2017, и это не основной проект. Установка NUnit3TestAdapter устранила проблему.
У меня та же проблема. Я использую Visual Studio 2017 Community Edition.
Я использовал эти шаги, чтобы успешно обнаружить все мои тестовые случаи и успешно выполнить его:
Сначала зайдите в Расширения и обновления, установите тестовый адаптер NUnit3. Если у вас уже есть, просто включите его.
Перезагрузите Visual Studio 2017, он автоматически предложит
установите расширение, если в подсказке указано, что задача должна быть продолжена
Установка, просто нажмите "Завершить задачу".
После этого перестройте ваш тестовый проект, и теперь все тестовые наборы будут идентифицированы, и вы можете приступить к запуску тестовых наборов.
В моем случае переустановка адаптера Nunit3, удаление временных папок, изменение архитектуры и ничего не получалось. Это из-за Демона Решарпера вызвало проблему.
Add or Remove Programs> Find Resharper > Repair > Install again > Restart VS
Это решает проблемы.
Эта ошибка может произойти для асинхронных тестов, если у вас неправильный тип возврата. Тип возвращаемого значения должен быть Task, а не void.
После добавления TestAdapterPath в коммандер у меня все заработало:
vstest.console.exe Xom.Gci.Lvf.FileParserInvoker.UnitTests.dll /TestAdapterPath:"C:\****\****\{SolutionFolder}"
В моем случае тесты были обнаружены, но их выполнение привело к "Test Not Available..." и (не) известному: "Убедитесь, что обнаружитель тестов и исполнители зарегистрированы, а настройки версии платформы и фреймворка соответствуют требованиям, и попробуйте снова".
ошибка не зависела от Visual Studio (тестировалась с помощью инструментов dotnet CLI и почти голого теста UNIT) и была только при нацеливании на .NET 4.7.1. Приложение dotnetcore работает отлично.
Также при выполнении тестов с помощью Nuint3 CLI nunit3-console.exe Tests.csproj
показывает ошибку:
"Либо сборка не содержит тестов, либо подходящий тестовый драйвер не найден".
ошибка была в том, что тест-адаптер не был найден на (подключенном) сетевом диске или общем ресурсе и был решен путем его локального копирования и повторного запуска.
Если вы выполняете свои тесты в докере с использованием многоэтапного построения и тесты не найдены. Убедитесь, что вы скопировали все файлы, а не только файлы проекта, как показано ниже в разделе 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