Я боровся з VS 2017 з моменту встановлення. Тепер, схоже, Unit Tests запускається лише з командного рядка "тест на dotnet".

Мій проект - .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( див. повідомлення SO )
• для NUnit переконайтеся, що встановлений адаптер та та сама версія (3), що і пакет NUnit
• test -> test settings -> default processor architecture встановлено на x86

Питання
Чи може хто-небудь, будь ласка, надати робочий приклад рішення .Net Core 1.1.0 у VS2017 (файли проекту .csproj), де дослідник тесту VS успішно знаходить одиничні тести АБО покажіть мені проблему у наведеному прикладі.

У моєму випадку виявилося, що мені просто довелося модернізувати свої тестові адаптери та тестові рамки. Зроблено.

Приклад використання диспетчера пакунків 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 (бібліотека портативних класів), тому що він може працювати на багатьох платформах.

Далі вам потрібно додати посилання на 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

У мене був той самий випуск, і він змусив його працювати, виконуючи наступні дії:

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

Забувши зробити тест класу громадськості Запобігти'S методи випробувань всередині , щоб бути виявленими

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

Коротка історія, після оновлення пакетів xUnit, Test.Sdk, xUnit.runner та відновлення проекту я зіткнувся з помилкою збирання:

Помилка xUnit1000 Тестові класи повинні бути загальнодоступними

На щастя, оновлена ​​версія кинула цей виняток, щоб позбавити мене певних проблем

Змінення тестового класу на загальнодоступне вирішило мою проблему

У моєму випадку я націлюю тестовий проект на « x64Архітектура» та параметр тестування «Архітектура» (тест-> Архітектура процесора за замовчуванням) було змінено на « x86. Вони не відповідали.

Після повернення тестових налаштувань Архітектура x64та відновлення всіх тестів були виявлені знову.

У мене були проблеми з VS 2017, знаходячи свій UnitTest. Іван не задався точною проблемою - але це було першим результатом пошуку в Google, тому я хотів поділитися своєю проблемою.

У мене було застаріле рішення, яке поверталося з VS2010 і переходило на VS2013, VS2015. Зараз у VS2017, схоже, простори імен для [TestMethod]атрибутів змінилися.

До того, як це використовували

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

Я створив новий тест.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, щоб містити тестові приклади пристрою.

для мене питання, чи я помилково розмістив тестові вікна у внутрішньому класі

[TestClass]
  internal class TestLib {
}

що спричинило невстановлення тестових вікон.

Будьте впевнені, що ви використовуєте правильний 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>

але я не думаю, що це зайве.

Я знаю, що ОП вказала це у своєму контрольному списку, але легко не помітити цю точку, роблячи чисту установку 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 у своєму файлі 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')" />

Щоб вирішити проблему,

1. Клацніть правою кнопкою миші на проект та виберіть «Вивантажити проект».
2. Клацніть правою кнопкою миші проект та виберіть "Редагувати"
3. Видаліть рядок, який імпортує стару версію адаптера.
4. Клацніть правою кнопкою миші на проект і виберіть «Перезавантажити проект».
5. Відновіть рішення / проект

Якраз була така проблема, оскільки візуальна студія не змогла знайти мої тести, не побачила кнопки, щоб запустити їх, крім методу, і вони не були зібрані, виконавши всі тести в проекті.

Виявляється, мій тестовий клас був не загальнодоступним! Оприлюднення це дозволило VS виявити тести.

Для мене було простіше створити новий тестовий проект, який ідеально працює з Visual Studio 2017 ... і просто скопіювати тестові файли, додати посилання та пакунки NuGet за потребою.

У моєму випадку це був проект, який я модернізував тестовий проект з більш ранньої версії .Net. у app.config у мене були прив'язки до збірок до попередніх версій залежних зборів.

Після виправлення зв'язкових зв'язків у app.config мої тести були виявлені.

Відкриття

Наведені вище відповіді не працювали для мене (перезапуск, оновлення до версії 1.1.18 ... Я вже був оновлений, видалення тимчасових файлів, очищення кешу NuGet тощо).

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

пакети.конфіг

<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.

Рішення

Просто відновлення моїх пакунків.config до версії 1.1.18 відновило функціональність моїх модульних тестів у VS. Здається, є деякі помилки, які не дозволяють побічних посилань на бібліотеки MSTest. Сподіваюся, це вам допоможе.

Більше інформації:

• Visual Studio 2017 Ent: 15.5.6 (я оновлювався з 15.0.1 з надією виправити цю проблему, але я мав її в обох)

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

Цей файл посилався на деякі DLL-файли в обов'язкових напрямках, які насправді не були в посиланнях на проект. Повторно додайте вкладиші, які строго необхідні для вашого проекту.

У моєму випадку саме проект UWP був присутнім у вирішенні проблеми.

Коли я розвантажив проект UWP, були виявлені тести. Коли я його завантажую назад, тест знову зникає.

Спробуйте розвантажити всі проекти та тримати лише тестовий проект. У програмі Test Runner з'являються десять розчинів для відновлення та тестовий шум. Завантажуйте проекти по черзі та щоразу відновлюйте рішення, щоб з’ясувати, який проект викликає проблему

зразок репо

Звіт про помилку VS

Питання

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

Обґрунтуйте випуск

Ви можете перевірити проблему, перейшовши в командний рядок і отримавши свою версію dotnet $ dotnet --version. Якщо ви бачите що-небудь, крім останньої встановленої вами версії, то ваша машина має певну невідповідність і не використовує правильну версію. Приклад ... Якщо у вас встановлено ядро ​​dotnet, 1.0.1але коли ви отримуєте версію в командному рядку, вона говорить1.0.0 про те, що проблема.

Рішення

Видаліть усі старі речі. Я почав лише з того, що мені потрібно було видалити (найдавніші версії dotnet rc), але він все ще дав неправильну версію при тестуванні проблеми. Врешті-решт я поступився чистим способом. Я ...

• Видалено всі програми візуальної студії (на моїй машині VS2015 та VS2017)
• Видалено всі версії ядра dotnet (навіть найсвіжіші)

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

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

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

• Дивіться @epestic публікацію в блозі, де він детальніше розповідає про виправлення проблеми.

Я спробував все, але нічого не допомогло. У моєму випадку я мав рішення з декількома тестовими проектами, і деякі з них використовували стару рамку для тестування MS, тому Visual Studio знайшов лише ті.

Я встановив пакети тестових рамок для всіх тестових проектів, як показано у прийнятій відповіді . Потім видалили посилання на старі інструменти якості, перезапустили Visual Studio і тепер я можу побачити всі тести.

Для C ++:

Оскільки для тестів на C ++ немає особливого питання, але тема дуже однакова, ось те, що мені допомогло, коли у мене виникли проблеми з виявленням тесту.

Якщо ви встановили лише розробку робочого столу за допомогою C ++ , тоді рішення також встановити розробку універсальної платформи Windows з додатковими інструментами C ++ Universal Windows Platform . Вибрати їх можна в веб-програмі установки візуальної студії.

Після цього відновіть свій тестовий проект, і тестове відкриття має працювати.

До речі, я створив блок тестового проекту у VS2017. Це може бути важливо, оскільки деякі користувачі згадували, що у них були проблеми з виявленням у проектах, які були перенесені з VS2015 на VS2017.

Видалення старої .dll має допомогти. Очищення тимчасових файлів, що знаходяться в каталозі% TEMP% за адресою C: \ Користувачі (ім’я вашого користувача) \ AppData \ Local \ Temp

У мене було те саме питання. Моє рішення було нормально, але раптом, коли я відкрив рішення, я виявив, що тести пішли.

Нарешті я знизив Microsoft.VisualStudio.TestPlatform.TestFrameworkі Microsoft.VisualStudio.TestPlatform.TestFramework.Extensionsпакунки перейшли до дуже старої версії (за допомогою менеджера NuGet) і з'явилися методи тестування. Потім я перейшов до останньої версії і все ще там був.

Тому просто понижуйте та оновлюйте пакети.

У моєму випадку жодне з перерахованих вище мені не допомагає. Але я знижую NUNit3TestAdapter до версії 3.8.0, а потім переходжу до останнього (3.10.0)

Іноді зміна простору імен тестів працює. Я мав структуру папки наступним чином:

A |___B | |___D |___C___E

Простір імен був рівним, як тести. <Name>, і вони не відображалися у тестовому вікні. Коли я змінив простір імен на структуру каталогу, показали всі тести. Тепер я міг повернутися до будь-якої іншої структури простору імен, яку я хочу.

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

Що стосується .NET Framework, в тестовому проекті раніше були посилання на такі DLL:

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

Я видалив їх і додав посилання на:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

А потім з’явилися всі тести і почали працювати так само, як і раніше.

Я раніше спробував майже всі інші пропозиції, але просто повторно посилався на тестові DLL-файли працювали нормально. Цю відповідь я розмістив для тих, хто в моєму випадку.

Я зіткнувся з тим же питанням, в моєму випадку, щоб вирішити

1. Я відкрив консоль Windows (ключ Windows + cmd).
2. Перейдіть до папки, в якій був створений проект.
3. Виконана команда "тест dotnet" - це в основному той самий тест, який виконує візуальна студія, але коли ви запускаєте її через консоль, вона дозволяє побачити повний слід.
4. Я отримав це повідомлення про помилку "Атрибут TestClass визначений у недержавному класі MSTest.TestController.BaseTest"
5. Тому я перейшов до тестового випадку і відзначив його як загальнодоступний, будуйте заново і мої тести відображаються правильно

Спочатку я намагався використовувати MSTest. Після цього я зміню його на тест Нуніта. Тоді я хотів підтримати MSTest. Я видалив усі коди і посилання nUnit, але Test Explorer не показав методів MSTest. Рішення: я видалив усі найпопулярніші посилання на mstest і перевстановив. Зроблено.

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

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

до

  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>

працювали.

У моєму випадку проблема полягала в тому, що тип проекту був встановлений на статичну бібліотеку (lib), і це повинна бути динамічна бібліотека (dll)