Модульные тесты не обнаружены в Visual Studio 2017
Я боролся с VS 2017, так как я установил его. Теперь кажется, что модульные тесты будут запускаться только из командной строки "dotnet test".
Мой проект.NET Core 1.1.1. У меня есть SDK и обновление фреймворка для 1.1.1.
Я попробовал образец на MSDN ( https://msdn.microsoft.com/en-us/library/ms182532.aspx), который также не работает точно так же.
Все пакеты NuGet для тестов и основного проекта являются актуальными. И тестовый проект и основной проект строят без ошибок. Тесты успешно запускаются из командной строки.
Кто-нибудь получил юнит-тесты для запуска в VS 2017, если да, то как?
Спасибо Джон
Обновление - Расширить
Вот пример простого тестового проекта, который не работает на GitHub. Это пример с xUnit, но я пробовал NUnit и визуальную студию, встроенную в MS тесты. Независимо от того, какое тестирование или какие изменения я делаю, я не могу заставить тестировщика VS найти какие-либо тесты.
Что я пробовал
- Удаление файлов кеша теста VS
DEL %TEMP%\VisualStudioTestExplorerExtensions - Перезапуск VS
- Проводник тестов закрытия / открытия
- для xUnit установлен
Microsoft.DotNet.InternalAbstractions( см. ТАК сообщение) - для NUnit убедитесь, что адаптер установлен и та же версия (3), что и в пакете NUnit
test -> test settings -> default processor architectureустановлен на x86
Вопрос
Может ли кто-нибудь предоставить рабочий пример решения.Net Core 1.1.0 в VS2017 (файлы проекта.csproj), где проводник тестов VS успешно находит модульные тесты ИЛИ покажите мне проблему в приведенном примере.
42 ответа
В моем случае оказалось, что мне просто нужно обновить свои тестовые адаптеры и тестовую среду. Готово.
Пример использования диспетчера пакетов NuGet:
Это просто сработало для меня (не знаю, является ли это результатом изменения рабочих пространств, которые что-то повредили):
Удаление файлов кэша теста VS в%TEMP%\VisualStudioTestExplorerExtensions и перезапустите 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 ваши ссылки будут выглядеть так,
<itemgroup>
<packagereference Include="Microsoft.NET.Test.Sdk" Version="15.0.0"></packagereference>
<packagereference Include="NUnit" Version="3.7.1"></packagereference>
<packagereference Include="NUnit3TestAdapter" Version="3.8.0"></packagereference>
</itemgroup>
Комментарий выше упоминает добавление,
<ItemGroup>
<Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>
Это не обязательно, но может помочь. Visual Studio автоматически добавляет его во все проекты модульных тестов, чтобы быстро находить проекты с тестами.
Если ваши тесты не отображаются в Visual Studio, первое, что нужно сделать, это закрыть свое решение, а затем снова открыть его. Кажется, в Visual Studio есть ошибки, которые не обнаруживают изменения в проектах при их редактировании.
Для получения дополнительной информации см. Тестирование.NET Core с NUnit в Visual Studio 2017
Забудьте сделать тестовый класс общедоступным, чтобы не было обнаружено методов теста внутри
У меня был проект xUnit по умолчанию, и я удалил образец UnitTest1.cs, заменив его тестовым классом контроллера, с парой тестов, но ни один не был найден
Короче говоря, после обновления пакетов xUnit, Test.Sdk, xUnit.runner и перестройки проекта я обнаружил ошибку сборки:
Ошибка xUnit1000 Тестовые классы должны быть открытыми
К счастью, обновленная версия выбросила это исключение, чтобы избавить меня от проблем
Модификация тестового класса для публичного исправления моя проблема
У меня была та же проблема, и я получил ее, выполнив следующие действия:
- Сначала закройте все открытые экземпляры 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 для обнаружения моих тестов.
В моем случае я нацеливаю тестовый проект на x64 Архитектура и настройка теста Архитектура (test-> Архитектура процессора по умолчанию) изменена на x86, Они не совпадали.
После того, как вернули тестовую настройку Архитектура в x64 и восстановить все тесты были обнаружены снова.
Для меня проблема была я ошибочно поместил тестовые случаи во внутренний класс
[TestClass]
internal class TestLib {
}
это привело к тому, что тест-кейсы не были опознаны.
У меня были проблемы с 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 обнаружил эти юнит-тесты.
Не читайте устаревшие статьи под MSDN. Соответствующие материалы по.NET Core находятся на сайте docs.microsoft.com.
https://docs.microsoft.com/en-us/dotnet/articles/core/testing/
Вообще говоря, вам нужно консольное приложение.NET Core, содержащее примеры модульных тестов.
Убедитесь, что вы используете правильный Microsoft.NET.Test.Sdk:
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
Не используйте предварительную версию. Или вы должны перейти на консольное приложение (не библиотека). У меня похожая проблема, но с последней версией (15.0.0) она снова начинает работать.
Также вам, возможно, придется добавить:
<ItemGroup>
<Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>
но я не думаю, что это необходимо.
Я знаю, что OP перечислил это в своем контрольном списке, но этот момент легко упустить из виду при чистой установке Visual Studio 2017 и настройке нового проекта. Помимо шаблона проекта NUnit и NUnit Framework необходимо отдельно установить адаптер NUnit, например, с помощью команды NuGet Install-Package NUnit3TestAdapter -Version 3.9.0, После этого Visual Studio Community 2017 начал обнаруживать юнит-тесты без проблем.
В моем случае Test Explorer не смог найти мои тесты после того, как я переместил проект в новое решение.
Ответ был просто, что у меня была ссылка на старый MS Test Adapter в моем проекте.
У меня был дубликат строки ниже для версии 1.1.11 MS Test Adapter в моем файле cs.proj:
<Import Project="..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props')" />
Решить проблему,
- Щелкните правой кнопкой мыши по проекту и выберите "Выгрузить проект".
- Щелкните правой кнопкой мыши проект и выберите "Изменить".
- Удалить строку, которая импортирует старую версию адаптера.
- Щелкните правой кнопкой мыши по проекту и выберите "Обновить проект".
- Восстановить решение / проект
Просто у меня была проблема с Visual Studio, которая не могла найти мои тесты, не могла видеть кнопку для их запуска, кроме метода, и они не были подняты при запуске всех тестов в проекте.
Оказывается, мой тестовый класс не был публичным! Обнародование позволило VS открыть для себя тесты.
Для меня было проще создать новый тестовый проект, который прекрасно работает с Visual Studio 2017... и просто скопировать тестовые файлы, добавить ссылки и пакеты NuGet по мере необходимости.
открытие
Приведенные выше ответы не сработали (перезапуск, обновление до версии 1.1.18 ... Я уже обновился, удаление временных файлов, очистка кеша NuGet и т. Д.).
Я обнаружил, что у меня были разные ссылки на MSTest.TestAdapter и MSTest.Framework в разных тестовых проектах (у моего решения их два). Один был указан в 1.1.18 как...
packages.config
<package id="MSTest.TestAdapter" version="1.1.18" targetFramework="net461" />
<package id="MSTest.TestFramework" version="1.1.18" targetFramework="net461" />
... но у другого есть ссылки на 1.1.11. Некоторые из приведенных выше ответов приводят к этому открытию, когда две версии библиотек обнаружились в моем временном каталоге (%TEMP%\VisualStudioTestExplorerExtensions\) после перезапуска Visual Studio.
Решение
Простое обновление моего packages.config до версии 1.1.18 - вот что восстановило функциональность моих модульных тестов в VS. Похоже, что есть некоторые ошибки, которые не допускают параллельные ссылки на библиотеки MSTest. Надеюсь, это поможет вам.
Больше информации:
- Visual Studio 2017 Ent: 15.5.6 (я обновил с 15.0.1 с надеждой исправить эту проблему, но у меня было это в обоих)
Решение удаляло мое app.config файл из моего проекта модульного тестирования. Тесты появятся снова!
Этот файл ссылается на некоторые библиотеки DLL в связывающих каталогах, которых на самом деле не было в ссылках проекта. Повторно добавьте сборочные привязки, которые строго необходимы для вашего проекта.
В моем случае я столкнулся с той же проблемой, чтобы решить
- Я открыл консоль Windows (клавиша Windows + cmd).
- Перейдите в папку, в которой был создан проект.
- Выполненная команда "dotnet test" - это в основном тот же тест, который выполняет Visual Studio, но когда вы запускаете его через консоль, он позволяет вам увидеть полную трассировку.
- Я получил это сообщение об ошибке "Атрибут TestClass определен в закрытом классе MSTest.TestController.BaseTest"
- Итак, я пошел к тесту и пометил его как общедоступный, построил заново, и мои тесты отображаются правильно.
В моем случае это был проект, в котором я обновил тестовый проект с более ранней версии.Net. в app.config у меня были привязки к предыдущим версиям зависимых сборок.
После исправления сборочных привязок в app.config мои тесты были обнаружены.
Иногда смена пространства имен тестов работает. У меня была структура папок следующим образом:
A
|___B
| |___D
|___C___E
Пространство имен было плоским, как Tests.<Имя>, и они не отображались в окне теста. Когда я изменил пространство имен на структуру каталога, обнаружились все тесты. Теперь я могу вернуться к любой другой структуре пространства имен, которую захочу.
Не забудьте построить свой проект!
Я перепробовал все, но ничего не помогло. В моем случае у меня было решение с несколькими тестовыми проектами, и некоторые из них использовали старую среду ms-test, поэтому Visual Studio нашла только их.
Я установил пакеты инфраструктуры тестирования для всех тестовых проектов, как показано в принятом ответе. Затем удалил ссылки на старые качественные инструменты, перезапустил Visual Studio и теперь я вижу все тесты.
Удаление старого.dll должно помочь. Очистка временных файлов, расположенных в каталоге%TEMP% в C:\Users(имя пользователя)\AppData\Local\Temp
Убедитесь, что ваш тестовый класс и метод НЕ являются статическими.
В случае.NET Framework в тестовом проекте раньше были ссылки на следующие библиотеки DLL:
Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions
Я удалил их и добавил ссылку на:
Microsoft.VisualStudio.QualityTools.UnitTestFramework
А потом все тесты появились и начали работать так же, как и раньше.
Раньше я пробовал почти все другие предложения, приведенные выше, но простая ссылка на тестовые библиотеки DLL работала нормально. Я отправил этот ответ для тех, кто в моем случае.
В моем случае ничто из перечисленного не поможет мне. Но я понижаю версию NUNit3TestAdapter до версии 3.8.0, затем обновляюсь до последней версии (3.10.0)
Проблема
Проблема в том, что 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, и тестовый проводник сразу нашел тест
Это может показаться излишним, но я потратил две недели, пытаясь исправить это другими способами. Если у вас возникла проблема, просто сделайте это, даже если вам потребуется несколько часов, чтобы удалить / переустановить элементы, это, вероятно, сэкономит ваше время.
Рекомендации
- Смотрите сообщение в блоге @epestic, где он дает более подробную информацию об устранении проблемы.
Я была такая же проблема. Мое решение было в порядке, но внезапно, когда я открыл решение, я обнаружил, что тесты прошли.
Наконец я понизил Microsoft.VisualStudio.TestPlatform.TestFramework а также Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions пакеты до очень старой версии (с помощью диспетчера NuGet) и методы тестирования. Затем я обновился до последней версии, и все же там были.
Так что просто понизьте и обновите пакеты.
В моем случае, это был проект UWP, присутствующий в решении, вызвавшем проблему.
Когда я выгрузил проект UWP, тесты были обнаружены. Когда я загрузил его обратно, тест снова исчез.
Попробуйте выгрузить все проекты и сохранить только тестовый проект. В Test Runner появятся десять восстановленных растворов и тестовый стенд. Загружайте проекты один за другим и перестраивайте решение каждый раз, чтобы выяснить, какой проект вызывает проблему
Для C++:
Поскольку для тестов C++ особого вопроса нет, но тема почти такая же, вот что мне помогло, когда у меня возникли проблемы с обнаружением тестов.
Если вы только установили разработку для рабочего стола с C++, то решением будет также установить разработку универсальной платформы Windows с помощью дополнительных инструментов универсальной платформы Windows C++. Вы можете выбрать их в веб-установщике Visual Studio.
После этого пересоберите ваш тестовый проект, и тестовое обнаружение должно работать.
Кстати, я создал проект модульного тестирования в VS2017. Может быть важно, потому что некоторые пользователи упоминали, что у них были проблемы с обнаружением в проектах, которые были перенесены с VS2015 на VS2017.
Для меня, изменение TargetFramework в тестовом проекте .csproj файл из
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
в
<PropertyGroup>
<TargetFramework>net46</TargetFramework>
</PropertyGroup>
работал.
Проверьте, включен ли тестовый адаптер NUnit 3. В моем случае я уже установил его давным-давно, но вдруг он как-то отключился. У меня ушло довольно много времени, прежде чем я решил проверить эту часть...
