Чому Visual Studio 2015/2017/2019 Test Runner не виявив мої тести xUnit v2

ОНОВЛЕННЯ: Додавання 2019 року; механізм інтеграції відкриття / бігуна такий самий, як у 2017 та 2015 роках, тому ключові речі, які можуть піти не так, однакові.

Я читав, чому бігун xUnit не знаходить мої тести, що висвітлює причини, які xUnit ніколи не зможе знайти ваші тести, але моя проблема інша - я впевнений, що з моїми тестами нічого не виходить; (вони працювали в інших середовищах, це, здається, просто моя машина) - Тест-програміст Visual Studio в Visual Studio 2015 [Community Edition] просто не показує жодного з моїх тестів. Я не роблю нічого віддалено захоплюючого; тести націлені на xUnit.net v2 на робочому столі.

Я заглянув у вікно "Вихід" і взагалі нічого не бачу під " Тест" на вкладці " Показати" на вкладках.

1. Усуньте винятки з виявлення з ваших запитів; перейдіть до вікна виводу (Ctrl-Alt-O), після чого переключіть показ виводу з випадаючого (Shift-Alt-S) на " Тести" і переконайтесь, що немає винятків відкриття

2. Тест | Налаштування тесту | Архітектура процесорів за замовчуванням може допомогти, якщо ваші тести мають специфіку x86 / x64 і виявлення викликає винятки, пов'язані з укусами, тобто не AnyCpu

3. Як запропоновано у цій відповіді (підкажіть, якщо методика допомагає) запуск бігу на консолі робочого столу ( інструкції ) може бути хорошим перехресним перевіркою для усунення інших можливостей, наприклад, налаштованих файлів конфігурації: -

   packages\xunit.runner.console.2.2.0\tools\xunit.console <tests.dll>

   ПРИМІТКА xunit.runner.consoleПакет застарілий - коли ви працюєте з VS, ви зможете dotnet testзапускати їх і в контекстах CI

Перегляньте документацію - вона є всеосяжною, актуальною, включає інформацію про усунення несправностей та приймає PR:

Важлива примітка. Якщо ви раніше встановили xUnit.net Visual Studio Runner VSIX (розширення), його слід спочатку видалити. Бігун Visual Studio зараз розповсюджується лише через NuGet. Щоб видалити його, перейдіть до Інструменти > Розширення та оновлення . Прокрутіть до нижньої частини списку, і якщо xUnit.net встановлений, видаліть його. Це змусить вас перезапустити Visual Studio.

Якщо у вас є проблеми з виявленням або запуском тестів, ви можете стати жертвою пошкодженого кеша бігуна у Visual Studio. Щоб очистити цей кеш, закрийте всі екземпляри Visual Studio, а потім видаліть папку %TEMP%\VisualStudioTestExplorerExtensions. Також переконайтесь, що ваш проект пов'язаний лише з однією версією пакета NuGet Runner Visual Studio ( xunit.runner.visualstudio).

Наступні кроки працювали для мене:

1. (Тільки якщо ви підозрюєте, що на вашій машині серйозний безлад - загалом, більш поширений випадок, що інтеграція візуальної студії просто ще не встановлена)

   Виконайте, DEL %TEMP%\VisualStudioTestExplorerExtensionsяк радили: -

   PS> del $env:TEMP\VisualStudioTestExplorerExtensions

2. Встановіть пакет NuGet xunit.runner.visualstudioу всі тестові проекти

   • Пакет:

     .paket\paket add nuget xunit.runner.visualstudio -i

     Вам потрібно закінчити наступне у вашомуpaket.dependencies :

     nuget xunit.runner.visualstudio version_in_path: true

     Зверніть увагу, що version_in_path: trueбіт важливий

   • Nuget: Перейдіть до консолі диспетчера пакунків (Alt-T, N, O) та

     Install-Package xunit.runner.visualstudio)

   Перебудуйте, щоб переконатися, що xunit.runnerкінець у вихідному режимі

3. Закрити тестовий провідник <- це був для мене недолік

4. Відкрийте тестовий провідник (Alt-S, W, T)

5. Виконати всі тести (Ctrl R, A)

Мені довелося змінити параметри тесту після зміни тестових проектів CPU на x64. Потім тести, де виявлено знову.

Жодне з перерахованих вище рішень для мене не працювало (dotnetcore 1.1, VS2017). Ось що це виправило:

1. Додати пакет NuGet Microsoft.TestPlatform.TestHost
2. Додати пакет NuGet Microsoft.NET.Test.Sdk

Це додатки до цих пакунків, які я встановив раніше:

• xunit (2.3.0-beta1-build3642)
• xunit.runner.visualstudio (2.3.0-beta1-build1309)

Встановіть xunit.runner.visualstudioпакет для тестового проекту

Виконайте такі дії:

1. Оновіть своє MsTest.TestAdapterта MsTest.TestFramework dll'sз nugget package manager.
2. Очистіть ваш розчин
3. Побудуйте своє рішення.

Я боровся з цим увесь день, працюючи з проектом ASP Core та xUnit 2.2.0. Для мене рішення було додавання посилання наMicrosoft.DotNet.InternalAbstractions

Я виявив це, коли намагався запустити тестовий проект вручну, з dotnet testяким не вдалося, але повідомив про InternalAbstractionsвідсутність. Я не бачив цієї помилки у вікні тестового виходу, коли автоматичне відкриття не вдалося. Єдиною інформацією, яку я бачив у вікні відкриття, був код повернення, який для мене тоді нічого не означав, але заднім числом, ймовірно, вказувало на помилку.

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

Переконайтесь, що ваш тестовий клас є загальнодоступним .

Причиною в моєму випадку було те, що збірка цілей була не однаковою між налагоджувачем проекту та тестовим виконавцем. Для уніфікації цих елементів:

1. Тест> Налаштування тесту> Архітектура процесора за замовчуванням. потім виберіть X64 або X86.
2. Проект> (ваш проект) Властивості> Створення (вкладка)> ціль платформи.

Після того, як вони ідентичні, відновіть рішення, тоді для вас з’являться методи тестування.

Провівши 2 дні ... нічого з перерахованого вище не працювало для мене. Єдиним "рішенням" було: Перейти до властивостей проекту -> Tab Build. Потім натисніть кнопку Додатково в правому нижньому куті панелі. Змініть "Інформація про налагодження:" на "повну" та натисніть кнопку ОК.

Ось знімки екрана:

Я використовую xUnit 2.2.0.

Моя проблема полягала в тому, що моє рішення не змогло знайти певні проблеми і app.configнамагалася їх вирішити. Помилка не відображалася у вікні тестового виводу у Visual Studio.

Я зміг виявити помилку, коли встановив xunit.runner.consoleі спробував запустити тести через командний рядок.

Як запустити тести xunit в CLI .

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

У мене був такий самий випуск із останньою версією VS 2017 (версія 15.5.7) та XUnit 2.3.1. Пакет xunit.runner.visualstudio був встановлений, проте тести не з'явилися у вбудованому тестовому досліднику VisualStudio.

Я працював над застарілим проектом, орієнтованим на .NET Framework 4.5. Однак, починаючи з версії 2.2. XUnit не підтримує .NET фреймворки з нижчим рівнем 4.5.2 (див. Примітки до випуску - XUnit 2.2: 19 лютого 2017 р.

Змінення цільової рамки тестового проекту на версію> = 4.5.2 працювало для мене. Вам не потрібно змінювати версію проекту, який ви тестуєте, мова йде лише про тестовий проект.

У мене була та сама проблема з Visual Studio 2019. Просто встановив наступні пакети NuGet, і проблема була вирішена.

1). xUnit

2). xunit.runner.visualstudio

3). Microsoft.TestPlatform.TestHost

4). Microsoft.NET.Test.Sdk

Це також може бути пов’язано з тим, що прапорець збірки не позначено для поточного проекту платформи в конфігурації збірки. Клацніть Побудувати | Менеджер конфігурацій, тоді переконайтеся, що в тестових проектах є галочка в стовпці збірки для платформи, яку ви використовуєте (наприклад, "x86").

Це, безумовно, було рішення, яке працювало на мене.

Переконайтесь, що ви не написали свої тести на одиницю в бібліотеці класів .NET Standard 2.0. Під час написання цього запису Visualstudio не підтримує запущені тести в бібліотеках класів netstandard2.0.

Перевірте тут з матрицею сумісності тестового бігуна:

https://xunit.github.io/#runners

Виникла подібна проблема з VS, не виявивши методів тестування. У моєму випадку у мене було статичне ключове слово з методом, який я видалив, і він працював.

[TestMethod]

Before: public static void Test1()

After: public void Test1()

1. Закрийте всі екземпляри Visual Studio
2. Перейдіть до% TEMP% \ VisualStudioTestExplorerExtensions \
3. Видаліть пов'язані з папками specrun
4. Спробуйте ще раз

дайте мені знати, дякую

У моєму випадку у мене було 2 різних тестових проекту в рішенні. Тести проекту 1 можна було знайти, але тести проекту 2 не змогли. Я виявив, що спочатку вивантаження тестового проекту 1, потім закриття VS> очищення моїх тимчасових файлів> повторне відкриття рішення> відновлення, дозволило VS виявити мої тести Project 2.

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

Я довго страждав від цієї проблеми.

• У мене було близько 100 проектів, різної версії було розгорнуто на різних серверах.

• Оновлення xunit з 2.2.0 до 2.3.1 не було вирішенням, оскільки збірка не була в 2.3.1.

Потім я просто оновив xunit.runner.visualstudio до 2.3.1 і все почало працювати нормально. Я використовував цю команду в консолі менеджера пакунків, щоб оновити мій пакет xunit.runner.visualstudio

Get-Project ComapanyName.ProjectName.*.Tests | Install-Package xunit.runner.visualstudio -Version 2.3.1

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

У VS 2017 спробуйте створити файл Запуск параметрів, наприклад, Default.runsettingsу вашому тестовому проекті. Якщо ваша основна lib - x64, вміст повинен бути:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <RunConfiguration>
    <TargetPlatform>x64</TargetPlatform>
  </RunConfiguration>
</RunSettings>

Потім виберіть цей файл у меню Тест -> Параметри тестування -> Виберіть файл тестових налаштувань.

Потім у розділі Тест -> Налаштування тесту, Архітектура процесора за замовчуванням знову виберіть правильну архітектуру.

Не забудьте очистити і скласти все рішення. Можливо, вам доведеться закрити і знову відкрити вікно Test Explorer. Шукайте будь-які додаткові помилки у вікні Output -> Test, щоб отримати додаткові підказки щодо неправильних типів архітектури.

Додаткові записи тестових налаштувань FYI можна знайти тут .

Є ще одна причина, яка може призвести до того, що Test Explorer не показує жодних тестів, і це пов'язано з новим портативним .pdbформатом файлів, запровадженим з Visual Studio 2017 / for .NET Core, який може зламати деякі інструменти VS. (Передумови: Див . Звіт про помилку "Mono.Cecil викликає OutOfMemoryException з новими PDB-кодами .csproj" .)

Чи не знайдено ваші тести через новий портативний .pdbформат (символи налагодження)?

• Відкрийте вікно виводу .
• Зміна вибору випадає для шоу виходу з до випробувань .

• Якщо ви бачите вихідні дані, подібні до наступного (можливо, повторення один раз для кожного з ваших тестів), то у вас є проблема, описана в цій відповіді:

  Exception System.OutOfMemoryException, Exception converting <SignatureOfYourTestMethod>
  Array dimensions exceeded supported range.

Якщо так, зробіть це, щоб вирішити проблему:

• Відкрийте Властивості тестового проекту (виберіть тестовий проект у Провіднику рішень та натисніть Alt+ Enter).
• Перейдіть на вкладку Build .
• Натисніть кнопку Додатково ... (знаходиться в самому кінці сторінки вкладки).
• У спадному меню з інформацією про налагодження виберітьnone , pdb-onlyчи full, але НЕ portable . Саме ця остання настройка призводить до того, що тести не знайдені.
• Натисніть кнопку ОК та очистіть і відновіть проект. Якщо ви хочете бути впевнені, перейдіть до вихідного каталогу тестового проекту та очистіть усі .pdbфайли перед відновленням. Тепер ваші тести повинні повернутися.

Зробись зі мною, коли я здійснив свої перші перші спроби ходьби з IntelliTest у VS 2017.

Іноді, коли тестовий проект автоматично створюється IntelliTest, посилання на збірку Microsoft.ExtendedReflection( ... \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Common7 \ IDE \ Extensions \ Microsoft \ Pex \ Microsoft.ExtendedReflection). dll ) відсутня. Після додавання згенеровані тести з’являться в тестовому досліднику після перекомпіляції.

Відмова: йдеться не про xunit з візуальною студією 2015, а про Visual Studio 2017 із тестовою програмою UWP-модуля (MSTest). Я потрапив до цієї теми, шукаючи те саме, тому, можливо, хтось інший зробить те саме :)

Для мене рішенням було оновлення пакетів наборів для MSTest.TestAdapter і MSTest.TestFramework. Здається, що створюючи тестовий додаток для UWP, ви автоматично не отримуєте останні версії.

Мою проблему було вирішено встановленням nuget xunit.runner.visualstudio

У моєму випадку у мене є декілька тестових проектів в одному і тому ж рішенні, і лише один із проектів не відображав "Тестовий провідник"

Я перейшов до "Керування Nuget Package for Solution", клацнувши правою кнопкою миші рішення.

Я помітив, що на вкладці "Консолідація" було декілька пакунків "Тест", які не синхронізувались між проектами. Я натиснув "Встановити", і мої пропущені тести з'явилися.

Я спробував більшість пропозицій вище, і нічого не вийшло. У моєму випадку я в команді, і для того ж рішення з'явилися тести для інших розробників. Отже, я спробував просто видалити свою папку .vs, але теж не пощастило.

Я остаточно видалив свою локальну папку і повторно клонував репо. Це вирішило це для мене.

Ось рішення, яке працювало на нас. Не найкраще, але, можливо, одне може принести користь.

Фон:

• Наші сценарії були розроблені з VS 2013 та використовували адаптер NUnit VS 2.1.
• Нещодавно ми перейшли до VS 2017, і коли відкрити те саме рішення - тест не відображатиметься в Test Explorer

Під час збирання ми побачимо це повідомлення:

[Informational] NUnit Adapter 3.10.0.21: Test discovery starting
[Informational] Assembly contains no NUnit 3.0 tests: C:\ihealautomatedTests\SeleniumTest\bin\x86\Debug\SeleniumTest.dll
[Informational] NUnit Adapter 3.10.0.21: Test discovery complete

Рішення (тимчасове):

• Видаліть адаптер NUnit 3.10 ...
• Встановіть адаптер NUnit VS 2.1 ..

Тепер показані тести.

Також перевірте, чи повністю порожній файл app.config (повністю порожній без абсолютно розмітки) входить до тестового проекту. Це був винуватцем моєї справи.

У моєму випадку я створив нову "Конфігурацію рішення", як показано на зображенні. Тому коли я вибираю свій власний як "Прод", він чомусь не розпізнає TestMehods. Повернення до "Налагодження" вирішує проблему

Я не знаю, чи хтось із вас також використовує JustMock, але мені довелося вимкнути профайлер у VS 2017 для тестового виявлення для роботи.