Почему Visual Studio 2015/2017/2019 Test Runner не обнаруживает мои тесты xUnit v2
ОБНОВЛЕНИЕ: добавление 2019; Механизм интеграции обнаружения/бегуна такой же, как в 2017 и 2015 годах, поэтому ключевые вещи, которые могут пойти не так, одинаковы.
Я читал, почему бегун xUnit не находит мои тесты, что объясняет причины, по которым xUnit никогда не сможет найти ваши тесты, но моя проблема в другом - я уверен, что в моих тестах нет ничего тонкого; (они работали в других средах, похоже, это просто мой компьютер) - в Visual Studio 2015 Runner Test Runner просто не показывается ни один из моих тестов. Я не делаю ничего отдаленно захватывающего; тесты нацелены на xUnit.net v2 на рабочем столе.
Я посмотрел в окне "Вывод" и вообще ничего не вижу в разделе " Тест" на вкладке " Показать вывод".
Ответы
Ответ 1
-
Устранить обнаруженные исключения из ваших запросов; перейдите в окно вывода (Ctrl-Alt-O), затем переключите вывод show из (Shift-Alt-S) на тесты и убедитесь, что исключений обнаружения нет
-
Как предлагается в этом ответе (повышайте его, если техника помогает)
запуск бегуна на рабочем столе (инструкции) может быть хорошей перекрестной проверкой для устранения других возможностей, например. измененные файлы конфигурации: -
packages\xunit.runner.console.2.2.0\tools\xunit.console <tests.dll>
-
Тестирование | Тестирование | Архитектура процессора по умолчанию может помочь, если ваши тесты заданы как x86/x64, а обнаружение запускает связанные с привязанностью исключения, т.е. AnyCpu
Прочитайте документацию - она полная, актуальная, включает в себя информацию об устранении неполадок и принимает PR: -
Важное примечание. Если вы ранее установили xUnit.net Visual Studio Runner VSIX (расширение), вы должны сначала удалить его. Бегун Visual Studio распространяется только через NuGet. Чтобы удалить его, перейдите в Сервис > Расширения и обновления. Прокрутите список до конца, и если xUnit.net установлен, удалите его. Это заставит вас перезапустить Visual Studio.
Если у вас возникли проблемы с обнаружением или запуском тестов, вы можете стать жертвой поврежденного кэша бегунов внутри Visual Studio. Чтобы очистить этот кеш, отключите все экземпляры Visual Studio, а затем удалите папку %TEMP%\VisualStudioTestExplorerExtensions
. Также убедитесь, что ваш проект связан только с одной версией пакета NuGet для Visual Studio (xunit.runner.visualstudio
).
Для меня работали следующие шаги:
-
(Только если вы подозреваете, что на вашем компьютере существует серьезная проблема - в общем, более распространенным случаем является то, что интеграция с визуальной студией просто не установлена)
Сделайте DEL %TEMP%\VisualStudioTestExplorerExtensions
в соответствии с рекомендациями: -
PS> del $env:TEMP\VisualStudioTestExplorerExtensions
-
Установите пакет 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
попадает в выходной каталог
-
Закрыть тестовый проводник < - это был недостающий бит для меня
-
Повторно открыть тестовый проводник (Alt-S, W, T)
-
Запустить все тесты (Ctrl R, A)
Ответ 2
Мне пришлось изменить настройки теста после изменения процессора тестовых проектов на x64.
Затем тесты, которые были обнаружены снова.
![Архитектура]()
Ответ 3
Ни одно из вышеперечисленных решений не помогло мне (dotnetcore 1.1, VS2017). Вот что это исправило:
- Добавить пакет NuGet
Microsoft.TestPlatform.TestHost
- Добавить NuGet
Пакет
Microsoft.NET.Test.Sdk
В дополнение к этим пакетам, которые я установил ранее:
- xunit (2.3.0-beta1-build3642)
- xunit.runner.visualstudio(2.3.0-бета1-build1309)
Ответ 4
Установить пакет xunit.runner.visualstudio
для тестового проекта
Ответ 5
Выполните следующие действия:
- Обновите свои
MsTest.TestAdapter
и MsTest.TestFramework
dll's
от nugget package manager
.
- Очистите ваше решение.
- Создайте свое решение.
Ответ 6
Я боролся с этим весь день, работая с проектом ASP Core и xUnit 2.2.0. Решение для меня заключалось в добавлении ссылки на Microsoft.DotNet.InternalAbstractions
Я узнал об этом при попытке запустить тестовый проект вручную с dotnet test
, который вышел из строя, но сообщил, что InternalAbstractions
отсутствует. Я не видел эту ошибку в окне тестового вывода, когда сбой автоматического обнаружения. Единственной информацией, которую я видел в окне открытия, был код возврата, который в то время не имел для меня ничего общего, но в ретроспективе, вероятно, указывалось на ошибку.
Ответ 7
Это случилось со мной несколько раз - когда я очищаю проект и строю его снова, он имеет тенденцию быть в порядке.
Ответ 8
Проведя 2 дня... ничего из вышеперечисленного не помогло мне. Единственным "решением" было: Перейти к свойствам проекта → Build Tab. Затем нажмите кнопку "Дополнительно" в правом нижнем углу панели. Измените "Debug Info:" на "full" и нажмите "OK".
Вот скриншоты: ![enter image description here]()
![enter image description here]()
Ответ 9
Причиной в моем случае было то, что целевая сборка не была одинаковой между отладчиком проекта и исполнителем тестов. Чтобы объединить эти элементы:
- Тест> Настройки теста> Архитектура процессора по умолчанию. затем выберите X64 или X86.
- Проект> (ваш проект) Свойства> Сборка (вкладка)> Цель платформы.
После того, как они будут идентичны, перестройте свое решение, тогда для вас появятся методы тестирования.
Ответ 10
Я использую xUnit 2.2.0.
Моя проблема заключалась в том, что мое решение не смогло найти определенные библиотеки, и app.config
пытался их решить. Ошибка не отображалась в окне вывода теста в Visual Studio.
Мне удалось определить ошибку, когда я установил xunit.runner.console
и попытался запустить тесты через командную строку.
Как запустить тесты xunit в CLI.
Ответ 11
Я могу предоставить решение для крайнего случая, с которым я столкнулся несколько дней назад. Это не будет решением, которое подходит для всех сценариев, описанных выше, однако, для крайнего случая, я его исправил.
У меня была такая же проблема с самой последней 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 работало для меня. Вам не нужно менять версию проекта, которую вы тестируете, речь идет только о самом тестовом проекте.
Ответ 12
Это также может быть связано с тем, что флажок сборки не отмечен для текущего проекта платформы в конфигурации сборки.
Нажмите "Построить | Configuration Manager, затем убедитесь, что в тестовых проектах есть галочка в столбце сборки для используемой платформы (например," x86").
Это было определенно решение, которое сработало для меня.
Ответ 13
Убедитесь, что вы не написали модульные тесты в библиотеке классов .NET Standard 2.0. Проигрыватель visualstudio не поддерживает выполнение тестов в библиотеках классов netstandard2.0 на момент написания этой статьи.
Проверить здесь для матрицы совместимости Test Runner:
https://xunit.github.io/#runners
Ответ 14
У меня была та же проблема с Visual Studio 2019. Просто установил следующие пакеты NuGet, и проблема была решена.
1). XUnit
2). xunit.runner.visualstudio
3). Microsoft.TestPlatform.TestHost
4). Microsoft.NET.Test.Sdk
Ответ 15
В моем случае у меня было два разных тестовых проекта в решении. Тесты проекта 1 можно было найти, но тесты Project 2 не смогли. Я обнаружил, что сначала выгрузив тестовый проект 1, затем закрыв VS > очистив временные файлы > повторно откройте решение > перестроить, разрешить VS обнаружить мои тесты Project 2.
Я предполагаю, что что-то должно противоречить двум тестовым проектам, и это был самый быстрый способ заставить меня работать и работать через несколько минут. Изломы могут быть разработаны позже:).
Ответ 16
Включение аналогичной проблемы с VS не обнаруживает методы тестирования. В моем случае у меня было статическое ключевое слово с методом, который я удалил, и он сработал.
[TestMethod]
Before: public static void Test1()
After: public void Test1()
Ответ 17
Я долго страдал от этой проблемы.
-
У меня было около 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
Ответ 18
Наиболее распространенным явлением для Visual Studio является попытка запуска тестов с использованием другой архитектуры, чем тестируемая библиотека. К сожалению, есть несколько мест, где кажется, что это может пойти не так.
В VS 2017 попробуйте создать файл параметров запуска, например. Default.runsettings
в вашем тестовом проекте. Если ваша основная библиотека - x64, содержимое должно быть:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<RunConfiguration>
<TargetPlatform>x64</TargetPlatform>
</RunConfiguration>
</RunSettings>
Затем выберите этот файл из Test → Test Settings → Select Test Settings File.
Затем в разделе Test → Test Settings, Default Processor Architecture, снова выберите правильную архитектуру.
Обязательно очистите и постройте все решение. Возможно, вам придется закрыть и снова открыть окно Test Explorer. Найдите дополнительные ошибки в окне Output → Test, чтобы узнать больше о неправильных типах архитектуры.
Дополнительные записи параметров тестирования FYI можно найти здесь.
Ответ 19
Есть еще одна причина, которая может привести к тому, что Test Explorer не будет показывать никаких тестов, и это связано с новым переносимым форматом файлов .pdb
, представленным в Visual Studio 2017/для .NET Core, который может сломать некоторые инструменты VS. (Предыстория: см. отчет об ошибке "Mono.Cecil вызывает OutOfMemoryException с новыми PDB-пакетами .csproj" .)
Не найдены ли ваши тесты из-за нового переносимого формата .pdb
(отладочные символы)?
- Откройте окно вывода.
- Измените раскрывающийся список для отображения результатов вывода на тесты.
-
Если вы видите вывод следующим образом (возможно, один раз для каждого из ваших тестов), то у вас есть проблема, описанная в этом ответе:
Exception System.OutOfMemoryException, Exception converting <SignatureOfYourTestMethod>
Array dimensions exceeded supported range.
Если да, сделайте это, чтобы решить проблему:
- Откройте тестовый проект "Свойства" (выберите тестовый проект в обозревателе решений и нажмите Alt + Enter).
- Перейдите на вкладку "Сборка".
- Нажмите кнопку "Дополнительно" (расположенная в самом конце этой закладки).
- В раскрывающемся списке с надписью "Отладка" выберите
none
, pdb-only
или full
, но НЕ portable
. Именно этот последний параметр не позволяет найти тесты.
- Нажмите "ОК", очистите и перестройте проект. Если вы хотите быть уверенным, перейдите в каталог вывода тестового проекта и очистите все файлы
.pdb
перед перестройкой. Теперь ваши тесты должны быть возвращены.
Ответ 20
Слушайте меня, когда я впервые совершил первые попытки с IntelliTest в VS 2017.
Иногда, когда тестовый проект автоматически создается IntelliTest, ссылка сборки на Microsoft.ExtendedReflection
(...\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\Pex\Microsoft.ExtendedReflection.dll) отсутствует.
При добавлении сгенерированные тесты будут отображаться в тестовом проводнике после повторной компиляции.
Ответ 21
Отказ от ответственности: речь идет не о xunit с visual studio 2015, а Visual Studio 2017 с приложением UWP unit test (MSTest). Я попал в эту нить, ища то же самое, поэтому, возможно, кто-то другой сделает то же самое:)
Решение для меня состояло в том, чтобы обновить пакеты nuget для MSTest.TestAdapter и MSTest.TestFramework. Похоже, что когда вы создаете приложение unit test для UWP, вы автоматически не получаете последние версии.
Ответ 22
Моя проблема была решена путем установки nuget xunit.runner.visualstudio
Ответ 23
В моем случае у меня есть несколько тестовых проектов в одном и том же решении, и только один из проектов не отображает "Тестировщик"
Я пошел в "Manage Nuget Package for Solution", щелкнув правой кнопкой мыши на решении.
Я заметил, что на вкладке "Консолидация" были некоторые пакеты "Тест" nuget, которые не синхронизировались между проектами. Я нажал "Установить", и мои отсутствующие тесты появились.
Ответ 24
Я перепробовал большинство предложений выше и ничего не получалось. В моем случае я работаю в команде, и тестирование других разработчиков для того же решения началось. Итак, я попытался просто удалить свою папку .vs, но там тоже не повезло.
В итоге я полностью удалил свою локальную папку и заново клонировал репо. Это решило это для меня.
Ответ 25
Вот решение, которое сработало для нас. Не самый лучший, но, может быть, кто-то может выиграть.
Фон:
- Наши скрипты были разработаны с VS 2013 и использовали NUnit VS Adapter 2.1..
- Недавно мы перешли на VS 2017, и когда откроем то же решение - test не будет отображаться в 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 Adapter 3.10...
- Установите адаптер NUnit VS 2.1..
Теперь тесты показаны.
Ответ 26
- Закройте все экземпляры Visual Studio
- Перейти к% TEMP%\VisualStudioTestExplorerExtensions\
- Удалить specrun связанные папки
- Попробуйте снова
дай мне знать спасибо
Ответ 27
Также проверьте, полностью ли пуст файл app.config(полностью пустой с абсолютно никакой разметкой) в тестовом проекте. Это было преступником в моем случае.
Ответ 28
В моем случае я создал новую "конфигурацию решения", как показано на рисунке. Поэтому, когда я выбираю свой пользовательский как "Prod", по какой-то причине он не распознает TestMehod. Переход к "Debug" решает проблему
![введите описание изображения здесь]()
Ответ 29
Я не знаю, используют ли некоторые из вас также JustMock, но мне пришлось отключить профилировщик VS 2017 для проверки обнаружения.
Ответ 30
В моем решении было много проектов различного типа, и я не мог запустить тестовый проект Xunit. Я выгрузил все из них, кроме моего проекта Xunit, а затем перестроил решение, которое показало тесты в visual studio, и я мог их запустить.