Я борюсь с VS 2017 с тех пор, как установил его. Теперь кажется, что модульные тесты запускаются только из командной строки «dotnet test».

Мой проект - .NET Core 1.1.1. У меня установлен SDK и обновление фреймворка для 1.1.1.

Я пробовал образец в MSDN (https://msdn.microsoft.com/en-us/library/ms182532.aspx), который также терпит неудачу точно так же.

Все пакеты NuGet для тестов и основного проекта актуальны. И тестовый проект, и основной проект строятся без ошибок. Тесты успешно запускаются из командной строки.

Has anyone gotten Unit Tests to run in VS 2017, if so how?

Спасибо, Джон


Обновить - Продлить

Вот пример простого тестового проекта, который не работает на GitHub. Это пример с xUnit, но я пробовал NUnit и Visual Studio, построенные в тестах MS. Независимо от того, какое тестирование или какие изменения я вношу, я не могу заставить средство запуска тестов VS найти какие-либо тесты.

Что я пробовал

  • Удаление файлов кэша тестов VS DEL% TEMP% \ VisualStudioTestExplorerExtensions
  • Перезапуск VS
  • Закрытие / открытие тестового проводника
  • для установленного xUnit Microsoft.DotNet.InternalAbstractions (см. Сообщение SO)
  • для NUnit убедитесь, что установлен адаптер той же версии (3), что и пакет NUnit
  • тест -> настройки теста -> архитектура процессора по умолчанию установлен на x86

Вопрос
Может ли кто-нибудь предоставить рабочий пример решения .Net Core 1.1.0 в VS2017 (файлы проекта .csproj), где обозреватель тестов VS успешно находит модульные тесты ИЛИ, покажите мне проблему в приведенном примере.

Ответы (37)

В моем случае это был проект UWP, присутствующий в решении, вызывающем проблему.

Когда я выгрузил проект UWP, обнаружились тесты. Когда загрузил обратно, тест снова пропадает.

Попробуйте выгрузить все проекты и оставить только тестовый. В Test Runner появятся десять решений для восстановления и тестовый шунт. Загружайте проекты один за другим и каждый раз перестраивайте решение, чтобы выяснить, какой проект вызывает проблему

образец репо

Отчет об ошибке VS

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

  • Сначала закройте все открытые экземпляры Visual Studio и удалите эту папку:% TEMP% \ VisualStudioTestExplorerExtensions (Запуск тестов с Visual Studio)
  • Перейдите в диспетчер пакетов NuGet и сначала установите Microsoft.NET.Test.Sdk (15.3.0-preview-20170425-07), а затем установите xunit.runner.visualstudio (2.3.0-beta1-build1309). См. Прилагаемый снимок экрана NuGet, чтобы увидеть все пакеты, которые мне пришлось установить, чтобы получить последнюю версию VS 2017 для обнаружения моих тестов.NuGet Screenshot

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

Я установил пакеты тестовой среды для всех тестовых проектов, как показано в этом ответе, затем удалил ссылки на старые инструменты качества, перезапустил Visual Studio, и теперь я могу видеть все тесты.

У меня тоже были проблемы с VS 2017, когда я нашел свой UnitTest. Это была не совсем та проблема, которую задавал Джон, но это был первый результат в google, который я искал, поэтому я хотел поделиться своей проблемой.

У меня было устаревшее решение, возвращавшееся из VS2010 по сравнению с VS2013, VS2015. Теперь в VS2017 кажется, что пространства имен для атрибута [TestMethod] изменились.

Раньше использовал

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

Я создал новый Test.dll в проекте и тот, который используется по умолчанию

Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0

Итак, я решил создать новый проект UnitTest из VS2017. Возможно, сработало бы и изменение ссылок на сборки для старого тестового проекта. С новым эталоном VS2017 обнаружил эти модульные тесты.

API для тестовых адаптеров для .NET Core изменился с выпуском Visual Studio 2017 и переходом от формата project.json к формату csproj. Это сделало существующие адаптеры dotnet-test - *, например dotnet-test-nunit, устаревшими.

Адаптеры были обновлены, но способ настройки и запуска тестов в Visual Studio или в командной строке с помощью dotnet test требует разных ссылок в ваших тестовых проектах.Остерегайтесь любой документации, в которой вы найдете справочные пакеты в формате dotnet-test - *, потому что они устарели.

Во-первых, ваш тестовый проект должен быть нацелен на конкретную платформу: .NET Core или .NET Framework. Он не может ориентироваться на .NET Standard, даже если код, который вы тестируете, является .NET Standard. Это связано с тем, что цель тестов указывает, на какой платформе запускать тесты. .NET Standard похож на PCL (Portable Class Library) в том смысле, что он может работать на многих платформах.

Затем вам нужно добавить ссылки на Microsoft.NET.Test.Sdk, выбранную вами тестовую среду и совместимый тестовый адаптер. Для NUnit ваши ссылки будут выглядеть так:

<группа товаров>
     
     
     

В комментарии выше упоминается добавление

<Группа элементов>
    

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

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

Дополнительные сведения см. В разделе Тестирование .NET Core с помощью NUnit в Visual Studio 2017.

Это просто сработало для меня (не знаю, является ли это результатом изменения рабочих пространств, которые что-то испортили):

Удаление файлов кэша тестов VS в% TEMP% \ VisualStudioTestExplorerExtensions и перезапуск VS2017.

Для меня изменение TargetFramework в файле .csproj тестового проекта с


   netcoreapp2.0 

От

до


   net46 

сработало.

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

У меня был проект xUnit по умолчанию, и я удалил образец UnitTest1.cs, заменив его тестовым классом контроллера с парой тестов, но ни одного не было найдено.

Короче говоря, после обновления пакетов xUnit, Test.Sdk, xUnit.runner и пересборки проекта я обнаружил ошибку сборки:

Ошибка xUnit1000 Тестовые классы должны быть общедоступными

К счастью, обновленная версия выбросила это исключение, чтобы избавить меня от некоторых проблем.

Изменение тестового класса, чтобы он был общедоступным, устранил мою проблему.

Удаление старой .dll должно помочь. Очистка временных файлов, находящихся в каталоге% TEMP% по адресу C: \ Users (yourusername) \ AppData \ Local \ Temp

В моем случае ничего из вышеперечисленного мне не помогло. Но я понижаю NUNit3TestAdapter до версии 3.8.0, а затем обновляюсь до последней версии (3.10.0)

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

Оказывается, мой тестовый класс не был публичным! Публикация позволила VS обнаружить тесты.

Открытие

Приведенные выше ответы не помогли мне (перезапуск, обновление до версии 1.1.18 ... Я уже был обновлен, удаление временных файлов, очистка кеша NuGet и т. Д.).

Я обнаружил, что у меня были разные ссылки на MSTest.TestAdapter и MSTest.Framework в разных тестовых проектах (в моем решении их два). Одно было указано на 1.1.18 вроде ...

packages.config



... а у другого есть ссылки на 1.1.11. Некоторые из приведенных выше ответов привели к этому открытию, когда две версии библиотек появились в моем временном каталоге (% TEMP% \ VisualStudioTestExplorerExtensions \) после перезапуска Visual Studio.

Решение

Простое обновление моего файла packages.config до версии 1.1.18 - вот что восстановило мои функциональные возможности модульных тестов в VS. Похоже, что есть некоторые ошибки, которые не позволяют параллельные ссылки на библиотеки MSTest. Надеюсь, это вам поможет.

Подробнее:

  • Visual Studio 2017 Ent: 15.5.6 (я обновился с 15.0.1 в надежде исправить эту проблему, но у меня это было в обоих)

Мне пришлось отключить (старый) файл runsettings. runsettings Filedisabled

Мне нужно было запустить это, которое обновило все ссылки адаптеров nunit для проектов модульных тестов:

Install-Package Nunit3TestAdapter

В моем случае оказалось, что ОДИН из моих тестовых классов не был публичным. Это мешало запуску всего пакета.

НО вот как я это понял ==> Кажется, что консоль 'Output' покажет вам журналы тестирования. Вам просто нужно переключиться со сборки на тесты.

Это досадно просто. Надеюсь, мое смущение поможет кому-то другому.

В случае .NET Framework в тестовом проекте раньше были ссылки на следующие библиотеки DLL:

Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions

Я удалил их и добавил ссылку на:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

И тут все тесты появились и начали работать так же, как и раньше.

Раньше я пробовал почти все остальные предложения, но простая ссылка на тестовые библиотеки DLL работала нормально. Я отправил этот ответ для тех, кто в моем случае.

В моем случае Test Explorer не смог найти мои тесты после того, как я переместил проект в новое решение.

Ответ был прост: в моем проекте есть ссылка на старый MS Test Adapter.

У меня был дубликат строки ниже для версии 1.1.11 тестового адаптера MS в моем файле cs.proj:

Чтобы исправить проблему,

  1. Щелкните правой кнопкой мыши проект и выберите «Выгрузить проект».
  2. Щелкните правой кнопкой мыши проект и выберите «Редактировать»
  3. Удалить строку, импортирующую старую версию адаптера.
  4. Щелкните правой кнопкой мыши проект и выберите «Перезагрузить проект».
  5. Ремонтное решение / проект

В моем случае проблема заключалась в том, что тип проекта был установлен как статическая библиотека (lib), и это должна быть динамическая библиотека (dll).

Я удалил папки BIN и OBJ для проекта. Как только я это сделал, все заработало.

Я знаю, что OP указал это в своем контрольном списке, но этот момент легко упустить из виду, выполняя чистую установку Visual Studio 2017 и настраивая новый проект. Помимо шаблона проекта NUnit и NUnit Framework, необходимо отдельно установить адаптер NUnit, например с помощью команды NuGet Install-Package NUnit3TestAdapter -Version 3.9.0. После этого Visual Studio Community 2017 без проблем начало обнаруживать модульные тесты.

У меня была такая же проблема при переходе с Visual Studio 2017 на 2019. Мне пришлось переустановить Microsoft.NET.Test.Sdk во всех моих тестовых проектах.

• 100001

В этом случае вам нужно выяснить, какой случай вызывает исключение stackoverflow.

Сначала пробовал использовать MSTest. После этого я меняю его на Nunit test. Затем я захотел поддержать MSTest. Я удалил все коды и ссылки nUnit, но в обозревателе тестов не отображались методы MSTest. Решение: я удалил все ссылки mstest nuget и переустановил. Готово.

Проверьте, включен ли тестовый адаптер NUnit 3. В моем случае я его уже давно установил, но вдруг как-то отключился. Мне потребовалось некоторое время, прежде чем я решил проверить эту часть ...

NUnit 3 Test Adapter Disabled

Мне было проще создать новый тестовый проект, который отлично работает с Visual Studio 2017 ... и просто скопировать тестовые файлы, добавить ссылки и пакеты NuGet по мере необходимости.

enter image description here

Я столкнулся с той же проблемой, в моем случае для решения

  1. Открыл консоль windows (клавиша windows + cmd).
  2. Перейдите в папку, в которой был создан проект.
  3. Выполняется команда «dotnet test», это в основном тот же тест, который выполняет Visual Studio, но когда вы запускаете его через консоль, он позволяет вам увидеть полную трассировку.
  4. Я получил это сообщение об ошибке «Атрибут TestClass определен в закрытом классе MSTest.TestController.BaseTest»
  5. Итак, я перешел к тесту и пометил его как общедоступный, построил заново, и мои тесты отображаются правильно

Решением было удаление моего файла app.config из моего проекта модульного тестирования. Тесты появятся снова!

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

В моем случае я нацеливаю тестовый проект на x64 Архитектура, а параметр теста Архитектура (тест> Архитектура процессора по умолчанию) изменен был установлен на x86. Они не совпадают.

После установки для параметра теста «Архитектура» значения x64 и перестройки все тесты были обнаружены снова.

В моем случае это был проект, в котором я обновил тестовый проект с более ранней версии .NET. в app.config у меня были привязки сборок к предыдущим версиям зависимых сборок.

После исправления привязок сборки в app.config мои тесты были обнаружены.

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

Наконец, я понизил версию Microsoft.VisualStudio.TestPlatform.TestFramework и Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions до очень старой версии (с использованием диспетчера NuGet) и методы тестирования показали вверх. Затем я обновился до последней версии, и они все еще были там.

Так что просто переходите на более раннюю версию и обновляйте пакеты.

Не читайте устаревшие статьи под MSDN. Материалы, относящиеся к .NET Core, находятся на docs.microsoft.com

.

https://docs.microsoft.com/en-us/dotnet/articles/core/testing/

Вообще говоря, вам необходимо консольное приложение .NET Core для хранения наборов модульных тестов.

Для меня проблема заключалась в том, что я по ошибке поместил тестовые примеры во внутренний класс

[TestClass]
внутренний класс TestLib {
}

Это приводило к тому, что тестовые случаи не были идентифицированы.

В моем случае оказалось, что мне просто пришлось обновить мои тестовые адаптеры и тестовую среду. Готово.

Пример использования диспетчера пакетов NuGet:

enter image description here

Иногда срабатывает смена пространства имён тестов. У меня была следующая структура папок:

А | ___ B | | ___ D | ___ C___E

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

Не забудьте собрать свой проект!

Убедитесь, что вы используете правильный Microsoft.NET.Test.Sdk:


Не использовать пререлизные. Или вам нужно перейти на консольное приложение (а не на библиотеку). У меня аналогичная проблема, но с последней версией (15.0.0) она снова начинает работать.

Также вам, возможно, придется добавить:

<Группа элементов>
  

но я не думаю, что это необходимо.

Для C ++:

Поскольку для тестов C ++ нет специального вопроса, но тема почти такая же, вот что помогло мне, когда у меня возникли проблемы с обнаружением тестов.

Если вы установили только Разработка настольных компьютеров с C ++, то решением также является установка Разработка универсальной платформы Windows с дополнительными инструментами Универсальной платформы Windows C ++. Вы можете выбрать их в веб-установщике Visual Studio.

После этого перестройте свой тестовый проект, и обнаружение тестов должно работать.

Кстати, я создал проект модульного тестирования в VS2017. Это может быть важно, потому что некоторые пользователи упомянули, что у них были проблемы с обнаружением в проектах, которые были перенесены с VS2015 на VS2017.

Проблема

Проблема в том, что Visual Studio «запуталась» в версиях ядра dotnet на машине. Когда я перешел в панель управления -> удалить программы, у меня было установлено 8 различных SDK ядра dotnet и время выполнения. Это каким-то образом приводило к тому, что VS выдает ошибку при попытке найти тесты.

Подтвердить выпуск

Вы можете проверить проблему, перейдя в командную строку и получив версию dotnet на $ dotnet --version. Если вы видите что-либо, кроме последней установленной вами версии, значит, ваш компьютер имеет несоответствие и использует неправильную версию. Пример ... Если у вас установлено ядро ​​dotnet 1.0.1, но когда вы получаете версию в командной строке, и она говорит 1.0.0, это проблема.

Решение

Удалить все старое. Я начал только с того, что мне нужно было удалить (самые старые версии dotnet rc), но он все равно дал неправильную версию при тестировании проблемы. В конце концов я согласился провести полную очистку. Я ...

  • Удалены все приложения Visual Studio (на моей машине VS2015 и VS2017)
  • Удалены все версии ядра dotnet (даже самые последние)

После того, как моя машина была полностью опустошена от всех VS и донетов, я установил только VS2017 (он поставляется с последней версией dotnet). Я создал тестовый проект xUnit, и тестовый проводник сразу нашел тест РЕШЕНО

This may seem like overkill but I spent two weeks trying to fix this in other ways. If your having the issue just do it, even though it may take you hours to uninstall/reinstall items it will probably save you time.

Список литературы

  • См. Сообщение в блоге @epestic , где он дает более подробную информацию об устранении проблемы.

2022 WebDevInsider