Тесту не знайдено. Переконайтеся, що встановлені тестові першовідкривачі та виконавці, налаштування версії платформи та фреймворку і повторіть спробу

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

Я отримую таку помилку:

Тесту не знайдено. Переконайтеся, що встановлені тестові першовідкривачі та виконавці, налаштування версії платформи та фреймворку і повторіть спробу.

Я відтворив проблему в більш простому налаштуванні:

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

Ви можете спробувати змінити архітектуру процесора за замовчуванням у тестовій настройці з X86 на X64. У моєму випадку це була проблема.

Це трапляється, якщо для цільової платформи вашого проекту, що перевіряється, встановлено значення x64.

Моя збірка теж не знаходила тестів. Моє налаштування та рішення для пошуку тестів такі.

Я використовую VSTS (Visual Studio Team Services) і маю збірку, налаштовану на оновлення пакетів NUGET під час кожної збірки. Я використовую NUnit і виявив, що запуск наступної команди NUGET (з консолі диспетчера пакетів у Visual Studio) для додавання бібліотеки NUnitTestAdapter до мого тестового проекту, а перевірка в Packa.config зробила тести запущеними у моїй збірці VSTS.

Install-Package NUnitTestAdapter

Як зазначає Моріс у коментарі до цього допису для NUnit3, використовуйте наступний пакет NUGET ( шукайте інші утиліти за посиланням, тобто: dotnet CLI та Paket CLI)

Install-Package NUnit3TestAdapter

Сподіваюся, це допомагає.

У моєму випадку довелося:

1) перетворити тестовий proj на netcore 2.0 (був netstandard 2.0)

2) додати nuget-пакет xunit.runner.visualstudio

Довідка: http://www.neekgreen.com/2017/11/20/xunit-no-test-is-available/

Я отримав цю помилку та зміг її усунути.

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

Я використовую MSTest. Для мене це невідповідність версії та відсутність іншого залежного пакету -

1) Моя папка пакунку містить лише пакет MSTest.TestFramework.1.2.1. У моєму файлі проекту (.csproj) посиланням у назві цілі був пакет MSTest.TestAdapter.1.2.0, якого не було в папці пакета. Мій пакет.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 з ураженої машини.

1. Встановіть останню версію Nunit та NUnitTestAdapter із пакета NUGET.
2. Перейдіть до -> Тест -> Параметри тесту -> Архітектура процесора за замовчуванням -> Змінити на X64
3. Побудуйте рішення.
4. Це вирішить проблему запуску тесту та налагоджувача під час модульного тестування, і вона почне працювати.

Я зіткнувся з тією ж проблемою у VSTS за допомогою .Net 4.6.2. Якщо ви бачите це з виводу консолі VSTS, обхідний шлях, наданий @Sushil, все ще працює у VSTS і необхідний. На жаль, завдання "Тестові збірки", надане корпорацією Майкрософт, проходить, тож ви навіть не знаєте, що проблема є, якщо ви не перевірите результат і не знайдете жодного з ваших тестів, фактично виконаних!

Якщо ви виконуєте свої тести всередині докера за допомогою багатоступеневої побудови, і тести не знайдені. Обов’язково скопіюйте всі файли, а не лише файли проектів, як показано нижче в розділі 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

Я виправив цю проблему в тестовому проекті VS 2017 & 4.6.2, виконавши такі дії:

1. Видаліть посилання на Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll та розширення
2. Встановіть пакет Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated nuget

Переконайтеся, що у вас встановлено nuget "Microsoft.NET.Test.Sdk".

Зараз це відома проблема для .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

Я виправив цю проблему шляхом перевстановлення всіх випробувань , пов'язані пакети NuGet для проекту: Xunit, Xunit.runner.vistualstudio,Microsoft.Net.Test.Sdk

Я отримував подібну проблему і помітив, що якось app.configфайл був доданий до мого тестового проекту. Видалення цього конфігураційного файлу це виправило для мене.

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

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

Знайшли спосіб! Мабуть, не найортодоксальніший, але мені це допомогло поспіхом:

1. Оновіть пакети MSTest.TestAdapter та MSTest.TestAdapterFramework до версії 1.4.0 за допомогою Інструменти> Менеджер пакунків NuGet.
2. Очистіть розчин і знову запустіть тести.

Я не думаю, що у версії є щось особливе, але її оновлення, безумовно, очищає будь-які посилання, які є поганими у рішенні / проекті.

Це лише для підсумку рішення, висунутого @Sushil раніше.

Це відома проблема в Team Foundation Server 2015 RTM + оновлення 1 і буде виправлена ​​в посібнику оновлення 2 .

Існує обхідний шлях описується @Sushil тут , який включає додавання .runsettings файлу , що сили тест бігун інфраструктуру .NET (будь ласка , НЕ то, що ви повинні вказати його в діалоговому вікні «Додати / Змінити Test Run» , як додати його безпосередньо у редакторі процесу збірки буде ігноруватися).

Використовуючи .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

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

Я використав ці кроки, щоб успішно виявити всі свої тестові приклади та успішно запустити їх:

• Спочатку перейдіть до Розширення та оновлення, встановіть тестовий адаптер NUnit3. Якщо у вас вже є, просто увімкніть його.

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

• Після цього відновіть свій проект тестування, і всі тестові випадки тепер будуть ідентифіковані, і тепер ви зможете розпочати тестування.

У моєму випадку перевстановлення адаптера Nunit3, видалення тимчасових папок, зміна архітектури і нічого не спрацювало. Це спричинило проблему через Dehar Resharper.

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

Це вирішує проблеми.

Ця помилка може трапитися для асинхронних тестів, якщо у вас неправильний тип повернення. Тип повернення повинен бути Task, а не недійсним.

Після додавання TestAdapterPath в командувач, це працює для мене:

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

У моєму випадку тести були виявлені, але запуск призвів до "Тест недоступний ... " та (не) відомого: "Переконайтеся, що виявник та виконавці тесту зареєстровані, а налаштування версії платформи та фреймворку відповідні та спробуйте ще раз."

помилка не залежала від Visual Studio (перевірена за допомогою інструментів dotnet CLI та майже оголеного тесту UNit), і це було лише при націлюванні на .NET 4.7.1. додаток dotnetcore чудово працює.

Крім виконання тестів з Nuint3 CLI nunit3-console.exe Tests.csprojпоказує помилку:

"Будь-яка збірка не містить тестів, або належний драйвер тесту не знайдено."

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

якщо ви вже встановили тестовий адаптер у тестовому проекті, спробуйте видалити його з проекту та встановити його знову в тестовий проект.

Це базове виправлення працює для мене.

Спробуйте запустити 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>in vstest.console.exe.config

Я використовую 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 "

Для тих, хто стикається з подібною проблемою. Ось рішення, будь ласка, встановіть SpecFlowPlusRunner.

Я пробував інші рішення, такі як перевстановлення, видалення кеш-пам’яті тощо. Але рішення насправді інше, нам потрібно встановити SpecRun.SpecFlow2.3.0 для visualstudio 2017. Це вирішило проблему.

Сподіваюся, це допомагає всім.

Я зіткнувся з подібною проблемою, коли спробував nUnit у VS 2017, і це не основний проект. Встановлення NUnit3TestAdapterвиправлено проблему.