Visual Studio 2015 або 2017 не виявляє одиничні тести

EDIT 2016-10-19:

Первісне питання стосувалося проблеми, характерної для VS2015 CTP6 з тестовим бігуном XUnit. З відповідей видно, що в Visual Studio існує набагато ширша проблема з виявленням тестових підрозділів, що може виникнути в багатьох різних ситуаціях. Я прибрав своє запитання, щоб це відобразити.

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

Багато інших відповідей також виявилися корисними для кращого розуміння тонкощів бігуна тесту VS. Я ціную, що люди все ще діляться своїми рішеннями!

Оригінальне запитання 2015-04-10:

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

Коли я переходжу до Тестового провідника Visual Studio і натискаю "Виконати все", або коли я клацну правою кнопкою миші будь-який метод тестування та виберіть "Запустити тести", у вікні виводу я отримую наступне:

Could not load file or assembly 'Microsoft.VisualStudio.Web.ProjectSystem, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Я біжу Visual Studio 2015 CTP 6 на Windows 10 Pro Technical Preview, збірка 10041. Відділ Платформа .NET Framework версії , здається, не має значення - це відбувається на 4.0, 4.5.2і 4.6.

Я спробував виконати такі рамки тестування, і всі вони мають однакову поведінку:

• Microsoft.VisualStudio.QualityTools.UnitTestFramework v14.0.22609.0
• xunit v2.1.0-beta1-build2945 з xunit.runner.visualstudio v2.1.0-beta1-build1051
• NUnit v2.6.4 з NUnitTestAdapter v2.0.0

Я знайшов проблему на GitHub (xunit), яка виявилася схожою: Неможливо виявити тести # 295 , з цим коментарем команди xunit:

Майте на увазі, що, як повідомляється, Visual Studio 2015 CTP 5 було зламано багатьма людьми з тестуванням одиниць взагалі (не лише xUnit.net), тому не сподівайтеся, що це спрацює.

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

Я спробував їх пропозицію видалити папку %TEMP%\VisualStudioTestExplorerExtensions. На жаль, це не вирішило проблему.

Я помітив , що на насправді ReSharper в змозі виявити деякі тести. Він працює лише для тестів VS та NUnit, а не для xunit.

Має бути якась папка temp або кеш, яку мені потрібно очистити, але я знаю, що у Visual Studio їх багато, і не всі їх можна видалити без небажаних побічних ефектів.

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

Примітка. Зазвичай цей шлях знаходиться на C:\Users\(yourusername)\AppData\Local\Temp

Якщо включено @ Warren-P, ви можете перейти до папки темп, ввівши %temp%меню "Пуск" або запустити "Провідник файлів" і ввести %temp%в адресний рядок.

Можливо, ваш код складений з x64, тому потрібно включити архітектуру процесора за замовчуванням як X64.

Test > Test Settings > Default Processor Architecture > X64

• Перевірте, чи встановлений NUnit Test Adapter 2/3 у VisualStudio.
  (Tools>Extensions and Updates )

• Переконайтесь, що обрана правильна архітектура процесора:
  (Test>Test Settings>Default Processor Architecture)

EDIT 2016-10-19 (сценарій PowerShell)

Це питання все ще повертається раз у раз. Я написав невеликий фрагмент PowerShell для автоматичного очищення відповідної папки / файлів кеш / темп для мене. Я ділюсь цим для майбутніх читачів:

@(
"$env:TEMP"
"$env:LOCALAPPDATA\Microsoft\UnitTest"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ComponentModelCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\Designer\ShadowCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ImageLibrary\cache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio Services\6.0\Cache"
"$env:LOCALAPPDATA\Microsoft\WebsiteCache"
"$env:LOCALAPPDATA\NuGet\Cache"
) |% { Remove-Item -Path $_ -Recurse -Force }

Заздалегідь закрийте Visual Studio, і, мабуть, буде гарною ідеєю перезавантажити потім.

Видалення папки TEMP може не знадобитися, а в деяких випадках навіть небажане, тому я рекомендую спробувати, не очищаючи папку TEMP спочатку. Просто опустіть "$env:TEMP".

Оригінальна відповідь 2015-04-12

Проблему було вирішено після ретельного очищення темп / кеш-папок, пов’язаних із Visual Studio.

Оскільки у мене не було часу переглядати все по одному, а потім перевіряти між ними, я, на жаль, не знаю, хто з них насправді спричинив проблему.

Ось які саме кроки я зробив:

1. Закрита візуальна студія
2. Використовується CCleaner для очищення системних tempфайлів та папок браузера

3. Очищено / видалено вручну такі файли / папки:

   • %USERPROFILE%\AppData\Local\assembly
   • %USERPROFILE%\AppData\Local\Microsoft\UnitTest
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\Designer\ShadowCache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ImageLibrary\cache
   • %USERPROFILE%\AppData\Local\Microsoft\VisualStudio Services\6.0\Cache
   • %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache
   • %USERPROFILE%\AppData\Local\NuGet\Cache
   • %USERPROFILE%\AppData\Local\Temp

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

У Visual Studio 2015 (оновлення 3), якщо ви хочете приєднати тести до тестового провідника, тоді вам доведеться встановити тестовий адаптер NUnit. Завантажте адаптер на вкладці Інструменти-> Розширення та оновлення-> Інтернет (потрібно шукати адаптер ) -> Завантажити . Перезапустивши Visual Studio, ви можете побачити зміни для тестової основи.

У мене немає повної відповіді на це, але я визначив деякі речі, граючи з тестовим проектом:

1. Те, xunit.runner.aspnet : 2.0.0-aspnet-beta4що, здається, є частиною офіційного випуску beta4 aspnet5, не працює у Visual Studio.
2. Натомість використання "xunit": "2.1.0-*"та "xunit-runner.dnx": "2.1.0-*"пакети DO працюють у Visual Studio.
3. Для того, щоб VS виявила тести, у вашому проекті ОБОВ'ЯЗКОВО є команда SINGLE під назвою "test", яка виконує "xunit.runner.dnx". Додавання додаткових команд може порушити її.
4. Якщо вікно Test Explorer все ще залишається порожнім, ВИДАЛУЙТЕ команду "тест" з вашого проекту, а потім знову складіть рішення, а потім додайте команду "test" назад до project.json.
5. Очищення всіх кешів за пропозицією @ Fred-Kleuver може допомогти, але я не зробив всіх кроків ізольовано, тому не впевнений.

Це актуально, згідно з VS 2015 CTP 6, використовуючи версії beta4, а не щоденні газети.

У мене був приклад, коли деякі тести не збиралися, тому що я робив їх asyncтакими:

public async void This_IsMy_UnitTest()

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

Не після 3 чистого і складання + перезавантаження VS.NETя побачив тестовий запуск і провал, що вказує, що я забув додати Taskтип повернення:

public async Task This_IsMy_UnitTest()

Після оновлення були знайдені та працювали коректні тести. Це може бути кращим випадком, але asyncтести на використання awaitв межах, але неправильність підпису можуть викликати цю саму проблему, і це не перший раз, коли я це робив.

Перейдіть до менеджера пакунків Nuget і завантажте Nunit Adapter так, як слід.

У мене був той самий pronlem, але папка "% TEMP% \ VisualStudioTestExplorerExtensions" не існувала на моїй машині, тому я читав пости, у мене була ідея створити її, і вона працює. Тестовий дослідник тепер може показати всі мої тести. Дякую.

Просто перезапустіть Visual Studio і в Test Explorer зробіть «Виконати все» ... Потім усі мої тести виявлені.

У моєму випадку (Visual Studio Enterprise 2015 14.0.25425.01, оновлення 3, Resharper 2016.2) мені просто потрібно було зробити чисте рішення з меню збірки. Після відновлення рішення потім тест-дослідник "прокинеться" і знову знайде всі тести.

У моєму випадку рішення було просто встановити розширення NUnit 3 Test Adapter на мою Visual Studio 2015.

У моєму випадку проблема полягала у «між стільцем та клавіатурою». Я перейшов до конфігурації в Менеджері конфігурацій, яка не включала мої тестові проекти одиниці на збірку. Повернення до конфігурації (наприклад, налагодження), яка включає всі проекти, які вирішили проблему.

У моєму випадку MSTest під VS 2015 ігнорував тести з тестовими (тобто методами) іменами, довжиною яких перевищував 174 символи. Скорочення назви дозволило бачити тест. Це було визначено за допомогою відгадки та маніпулювання тестовою назвою.

Це, мабуть, не допоможе більшості людей, але хтось недосвідчений на тестуванні блоку написав метод тестування, який повернувся boolзамість void:

[TestMethod]
public bool TestSomething()

Зміна типу повернення для voidвирішення проблеми.

Переконайтесь, що xunit.runner.visualstudioу вашому тестовому проекті пакет пакетів.config є пакунком, а також він був відновлений правильно.

Я знаю, що це не було випадковим питанням, але це могло б заощадити час для когось, як я.

Я хотів би лише додати, що я знайшов зовсім інше рішення для вищезазначених.

Я оголосив свій тестовий клас, як показано нижче:

[TestClass]
class ClassificationTests
{
   //unit tests
}

Як тільки я додав publicмодифікатор до класу, він працював так, як очікувалося!

Якщо ви орієнтуєтесь на .NET Standard або .NET Core, вам потрібно використовувати пакет NuGet для тестового адаптера NUnit, а не розширення .

Рекомендується встановити адаптер від NuGet, якщо ви тестуєте проекти .NET Core або .NET Standard. Адаптер VSIX не підтримує .NET Core, оскільки він не може орієнтуватися на декілька платформ.

Джерело: NUnit GitHub Wiki

.

Також перевірте там поширені запитання:

Мої тести не відображаються у Visual Studio 2017?

• Ви використовуєте пакет NuGet?
• Використовуєте версію 3.8.0 або новішу з пакету NuGet?
• Чи націлені ваші тести на .NET Core або повний .NET Framework? (Дивись вище)
• Ви додали посилання на пакет для Microsoft.NET.Test.Sdk?
• Ви перезапустили Visual Studio? Це все ще трохи вдало.

Джерело: NUnit GitHub Wiki

Це сталося зі мною, оскільки мій тестовий проект містив app.config. Її автоматично додавали пакети NuGet для перенаправлення збірки, але мої тести, здавалося, без проблем працювали.

Дивіться: https://developercommunity.visualstudio.com/comments/42858/view.html .

У мене була така ж проблема. Я просто почистив і відновив проект, і я зміг побачити тести, яких бракувало.

Вискакує, щоб поділитися своїм рішенням. Я був у Windows 10, Visual Studio 2015, NUnit 3.5, NUnit Test Adapter 3.6 (через NuGet, не розширення VISX), і жоден з моїх тестів не був виявлений. Моя проблема полягала в тому, що в проекті "Тести" мого рішення якось створено ярлик до папки "Документи" в папці проекту. Я здогадуюсь, що тестовий адаптер бачив ярлик і зависав, намагаючись зрозуміти, що з ним робити, в результаті чого не відображалися тести блоку.

Видалення файла \ AppData \ Local \ Microsoft \ VisualStudio \ 14.0 \ 1033 \ SpecificFold‌ erCache.xml вирішило проблему для мене.

Ця тема дещо застаріла, але моє рішення щодо відсутнього статусу тесту у VS2015:

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

Мене також вкусила ця чудова маленька особливість, і нічого описаного тут не працювало на мене. Це було, поки я ще раз не перевірив вихід збірки і не помітив, що відповідні проекти не будуються. Візит до менеджера конфігурації підтвердив мої підозри.

Visual Studio 2015 із задоволенням дозволив мені додавати нові проекти, але вирішив, що будувати їх не варто. Як тільки я додав проекти до складання, він почав чудово грати.

Я вирішив це, змінивши X64 на: Клацніть правою кнопкою миші на проект -> Властивості -> Збірка -> Ціль платформи -> Будь-який процесор

Якось мій проект був створений як статична бібліотека (.lib) . Змінивши це в Динамічну бібліотеку (.dll) , тести, де їх виявлено правильно Visual Studio 2012.

My Unit Test Project ->
Properties ->
Configuration Properties ->
General ->
Configuration Type

Мені було так просто виправити проблему, як:

• Виберіть проект Тестовий блок
• Натисніть кнопку "Показати всі файли" в Провіднику рішень, і нові дерева тимчасових файлів з'являться в дереві файлів Провідника рішень в межах "obj \ x86 \ Debug".
• Видаліть ці тимчасові файли та відновіть проект.
• Спробував запустити тести і працював !.

У нас була така ж проблема. У нас є велике рішення VS 2015 з кількома проектами C # і ще більше тестових проектів.

Тестове відкриття Решарпера спрацювало чудово, але VS Test Explorer пошкодив жалю.

Виявляється, проекти не мали однакової версії MsTest TestFramework та TestAdapter, і що іноді вони використовували NuGets та інші часи добрі старі посилання, і це, очевидно, не підтримується (настільки для такого дорогого IDE).

Видалення всіх посилань Microsoft.VisualStudio.Test * та додавання / оновлення двох MSTest NuGets виправили проблему.

Я вирішив цю проблему, зрозумівши, що цільова рамка мого тестового проекту відрізняється від тестованого проекту. Так, я викликав цю проблему, змінивши цільовий фреймворк із стандартного (Project> Properties> Application), але не вдався до цього для тестового проекту, який був створений через кілька тижнів. Невідповідність не спричинила помилку компілятора, але це призвело до попередження у вікні списку помилок . Як тільки я вибрав варіант для відображення попереджень, рішення було очевидним.