Visual Studio 2015 или 2017 не обнаруживает модульные тесты

РЕДАКТИРОВАТЬ 2016-10-19:

Первоначальный вопрос был о проблеме, специфичной для VS2015 CTP6 с тестером XUnit. Из ответов ясно, что существует гораздо более широкая проблема с обнаружением модульных тестов в Visual Studio, которая может возникать во многих различных ситуациях. Я очистил свой вопрос, чтобы отразить это.

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

Многие другие ответы также оказались полезными для лучшего понимания тонкостей тестера VS. Я ценю, что люди все еще делятся своими решениями!

Оригинальный вопрос 2015-04-10:

Со вчерашнего дня мой Visual Studio Test Explorer не обнаруживает тесты ни для одного из моих проектов. Он также не показывает зеленую полосу загрузки после сборки.

Когда я захожу в проводник тестов 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.

Должна быть какая-то временная папка или папка кэша, которую мне нужно очистить, но я знаю, что в Visual Studio их много, и не все из них могут быть удалены без нежелательных побочных эффектов.

К моему удивлению, очистка временных файлов, расположенных в %TEMP%каталоге, решила проблему для меня.

Примечание. Этот путь обычно C:\Users\(yourusername)\AppData\Local\Temp

Поскольку @ Warren-P включен, вы можете перейти к временной папке, введя %temp% войдя %temp%в меню «Пуск», или запустить «Проводник» и войти в адресную строку.

Возможно, ваш код скомпилирован с x64, поэтому необходимо включить архитектуру процессора по умолчанию как X64.

Test > Test Settings > Default Processor Architecture > X64

• Проверьте, установлен ли тестовый адаптер NUnit 2/3 в VisualStudio.
  (Tools>Extensions and Updates )

• Убедитесь, что выбрана правильная архитектура процессора:
  (Test>Test Settings>Default Processor Architecture)

РЕДАКТИРОВАТЬ 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

Проблема была «решена» после тщательной очистки папок temp / cache, связанных с Visual Studio.

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

Вот точные шаги, которые я предпринял:

1. Закрытая Visual Studio
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-*"пакеты работают в Visual Studio.
3. Чтобы VS обнаружил тесты, ваш проект ДОЛЖЕН иметь ОДНУ команду, которая называется «test» и запускает «xunit.runner.dnx». Добавление дополнительных команд может сломать его.
4. Если окно Test Explorer все еще остается пустым, УДАЛИТЕ команду «test» из своего проекта, затем пересоберите решение, а затем добавьте команду «test» обратно в project.json.
5. Очистка всех ваших кешей согласно предложению @ Fred-Kleuver может помочь, но я не сделал все шаги в изоляции, поэтому я не уверен.

Это актуально в соответствии с CTP 6 VS 2015 с использованием бета-версий, а не ежедневных газет.

У меня был случай, когда некоторые тесты не были бы выбраны, потому что я сделал их async следующим образом:

public async void This_IsMy_UnitTest()

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

Примерно после 3 чисток и сборок + перезапуска VS.NETя увидел тестовый прогон и потерпел неудачу, показывая, что забыл добавитьTask тип возврата:

public async Task This_IsMy_UnitTest()

После обновления юнит-тесты были найдены и работали корректно. Это может быть крайним случаем, но наличие asyncтестов для использования awaitвнутри, но не правильной подписи может вызвать ту же проблему, и я не первый раз делаю это.

Перейдите в менеджер пакетов Nuget и загрузите адаптер Nunit следующим образом.

У меня было то же место, но папка "% TEMP% \ VisualStudioTestExplorerExtensions" не существовала на моей машине, поэтому, когда я читал сообщения, у меня была идея создать ее, и она работает. Исследователь теперь может показывать все мои тесты. Спасибо.

Просто перезапустите Visual Studio и в Test Explorer выполните «Run All» ... Все мои тесты обнаружены.

В моем случае (Visual Studio Enterprise 2015 14.0.25425.01 Update 3, Resharper 2016.2) мне просто нужно было сделать чистое решение из меню Build. Затем перестройка решения приводит к «пробуждению» обозревателя тестов и повторному поиску всех тестов.

Решением в моем случае было просто установить расширение NUnit 3 Test Adapter для моей Visual Studio 2015.

В моем случае проблема была «между креслом и клавиатурой». Я переключился на конфигурацию в Configuration Manager, которая не включала мои проекты модульного тестирования при сборке. Возврат к конфигурации (например, отладка), которая включает все проекты, устранила проблему.

В моем случае MSTest под VS 2015 игнорировал тесты с именами тестов (т.е. методов), которые были длиннее 174 символов. Сокращение имени позволило увидеть тест. Это было определено путем предположения и проверки путем манипулирования именем теста.

Это, вероятно, не поможет большинству людей, но кто-то неопытный в модульном тестировании написал тестовый метод, который boolвместо void:

[TestMethod]
public bool TestSomething()

Изменение типа возврата, чтобы voidисправить проблему.

Убедитесь, что у вас есть xunit.runner.visualstudioпакет в вашем тестовом проекте packages.config, а также он был правильно восстановлен.

Я знаю, что это не относится к первоначальному вопросу, однако это может сэкономить время для кого-то вроде меня.

Я просто хотел бы добавить, что я нашел совершенно иное решение, чем приведенные выше.

Я объявил свой тестовый класс, как показано ниже:

[TestClass]
class ClassificationTests
{
   //unit tests
}

Как только я добавил publicмодификатор в класс, он заработал, как и ожидалось!

Если вы нацелены на .NET Standard или .NET Core, вам нужно использовать пакет NuGet для NUnit Test Adapter, а не расширение .

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

Источник: NUnit GitHub Wiki

,

Также проверьте FAQ там:

Мои тесты не отображаются в 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), и ни один из моих тестов не был обнаружен. Моя проблема заключалась в том, что в проекте Tests моего решения каким-то образом был создан ярлык для моей папки «Documents» в папке проекта. Я предполагаю, что тестовый адаптер видел ярлык и зависал, пытаясь понять, что с ним делать, что приводило к невозможности отображения модульных тестов.

Удаление файла \ 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 устранили проблему.

Я решил эту проблему, поняв, что Target Framework для моего тестового проекта отличается от тестируемого проекта. Да, я вызвал эту проблему, изменив целевую платформу по умолчанию (Project> Properties> Application), но не смог этого сделать для тестового проекта, который был создан несколько недель спустя. Несоответствие не вызвало ошибку компилятора, но привело к предупреждению в окне Список ошибок . Как только я выбрал опцию для отображения предупреждений, решение стало очевидным.