РЕДАКТИРОВАТЬ 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%
в меню «Пуск», или запустить «Проводник» и войти в адресную строку.источник
%TEMP%
меню Start Run, и он находит вашу временную папку для вас, не догадываясь, каково значение temp.%TEMP%
каталоге, заслуживает того, чтобы перестать работать.Возможно, ваш код скомпилирован с x64, поэтому необходимо включить архитектуру процессора по умолчанию как X64.
источник
Проверьте, установлен ли тестовый адаптер NUnit 2/3 в VisualStudio.
(Tools>Extensions and Updates )
Убедитесь, что выбрана правильная архитектура процессора:
(Test>Test Settings>Default Processor Architecture)
источник
РЕДАКТИРОВАТЬ 2016-10-19 (скрипт PowerShell)
Эта проблема все еще возвращается время от времени. Я написал небольшой фрагмент PowerShell, чтобы автоматизировать очистку соответствующей кеш / временной папки / файлов для меня. Я делюсь этим здесь для будущих читателей:
Обязательно закройте Visual Studio заранее, и, возможно, после перезагрузки будет хорошей идеей.
Удаление папки TEMP может быть необязательным, а в некоторых случаях даже нежелательным, поэтому я бы рекомендовал сначала не очищать папку TEMP. Просто опустите
"$env:TEMP"
.Оригинальный ответ 2015-04-12
Проблема была «решена» после тщательной очистки папок temp / cache, связанных с Visual Studio.
Так как у меня не было времени, чтобы пройти все по одному и затем проверить промежуточное, я, к сожалению, не знаю, какой из них на самом деле вызвал проблему.
Вот точные шаги, которые я предпринял:
temp
файлов и папок системы и браузераВручную очистили / удалили следующие файлы / папки:
%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
источник
\Microsoft\VisualStudio\14.0\ImageLibrary\ImageLibrary.cache
?Одной из причин этой проблемы является то, что ваш тестовый класс не является общедоступным. MSTest обнаруживает только тесты из открытых классов.
источник
В Visual Studio 2015 (обновление 3), если вы хотите прикрепить тесты в проводнике тестов, необходимо установить тестовый адаптер NUnit. Загрузите адаптер с вкладки «Инструменты» - «Расширения и обновления» -> «Онлайн» (необходимо найти адаптер ) -> Скачать . Перезапустив Visual Studio, вы можете увидеть изменения в тестовой среде.
источник
У меня нет полного ответа на это, но я определил некоторые вещи, играя с тестовым проектом:
xunit.runner.aspnet : 2.0.0-aspnet-beta4
что является частью официального выпуска beta4 aspnet5, не работает в Visual Studio."xunit": "2.1.0-*"
и"xunit-runner.dnx": "2.1.0-*"
пакеты работают в Visual Studio.Это актуально в соответствии с 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
:Изменение типа возврата, чтобы
void
исправить проблему.источник
Убедитесь, что у вас есть
xunit.runner.visualstudio
пакет в вашем тестовом проекте packages.config, а также он был правильно восстановлен.Я знаю, что это не относится к первоначальному вопросу, однако это может сэкономить время для кого-то вроде меня.
источник
Я просто хотел бы добавить, что я нашел совершенно иное решение, чем приведенные выше.
Я объявил свой тестовый класс, как показано ниже:
Как только я добавил
public
модификатор в класс, он заработал, как и ожидалось!источник
Если вы нацелены на .NET Standard или .NET Core, вам нужно использовать пакет NuGet для NUnit Test Adapter, а не расширение .
Источник: NUnit GitHub Wiki
,
Также проверьте FAQ там:
Источник: 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.
источник
Мне было так легко решить проблему как:
источник
У нас была такая же проблема. У нас есть большое решение VS 2015 с несколькими проектами на C # и еще большим количеством тестовых проектов.
Обнаружение теста Решарпера сработало просто отлично, но VS Test Explorer с треском провалился.
Оказывается, что в проектах не было одинаковых версий MsTest TestFramework и TestAdapter, и что иногда они использовали NuGets и другие старые добрые ссылки, и это явно не поддерживается (особенно для такой дорогой IDE).
Удаление всех ссылок на Microsoft.VisualStudio.Test *, а затем добавление / обновление двух MSTest NuGets устранили проблему.
источник
Я решил эту проблему, поняв, что Target Framework для моего тестового проекта отличается от тестируемого проекта. Да, я вызвал эту проблему, изменив целевую платформу по умолчанию (Project> Properties> Application), но не смог этого сделать для тестового проекта, который был создан несколько недель спустя. Несоответствие не вызвало ошибку компилятора, но привело к предупреждению в окне Список ошибок . Как только я выбрал опцию для отображения предупреждений, решение стало очевидным.
источник