Зараз я працюю над рішенням, яке наразі має 32 одиниці тестування. Я працював із тестовим бігуном resharper - який прекрасно працює. Всі тести працюють, усі тести показують правильний результат тесту. Тепер колега сказав мені, що тести не виконуються на його машині, використовуючи тест-випробувач Visual Studio. Вони не працюють ні на моїй машині, тому я можу виключити деякі локальні відсутні файли чи щось.

Тестовий провідник показує всі тести одиниць, але після натискання на "Виконати все" всі тести стають сірими і не показують результатів тестового запуску:

• Усі тестові класи є загальнодоступними
• У всіх тестових класах [TestClass]атрибут оголошено
• Усі методи тестування використовують [TestMethod]атрибут
• І код продуктивності, і тестові проекти орієнтуються на .NET 3.5.
• Я вже намагався чистої збірка мого рішення, і / або видалити всі obj, bin, Debugі Releaseпапки

Я б оцінив будь-які підказки, які могли б викликати таку поведінку.

Якщо ваші проекти не всі AnyCpu, ви також можете перевірити, чи відповідають наступні 2 налаштування:

1. [Тестовий проект правою кнопкою миші] -> властивості -> Збірка -> Ціль платформи - наприклад x64

2. [Головне меню] -> Тест -> Налаштування тестування -> Архітектура процесора за замовчуванням -> X64

Я виявив, що коли вони не відповідають моєму тестовому проекту, мовчки не вдасться запуститись.

У мене була така ж проблема в VS 2017. У моєму випадку вона вирішилася перезапуском VS.

Якщо ви використовуєте NUnit, а не MSTest, тоді вам знадобиться розширення тестового адаптера NUnit для Visual Studio 2012/2013.

Мені довелося змінити методи тестування на асинхронізацію, щоб повернути Завдання замість недійсного.

Потім тести були активними та запускаються в Test Explorer.

Перевірте, на яку основу написані тести (наприклад, nunit, xunit, VS test тощо) та переконайтеся, що встановлено правильне розширення тестового адаптера / бігуна.

Для мене відсутній тестовий адаптер NUnit 3, і я підтвердив необхідний номер версії, переглянувши версію залежності nunit.framework (виберіть .dll у дереві Dependency в Solution Explorer і натисніть F4, щоб відкрити вікно властивостей).

TLDR: Оновіть тестові пакети, загляньте у вихідну -> тестову консоль

Я боровся з цим протягом півтора днів. так ось що я зробив, щоб вирішити це:

Симптоми

1. 5 одиничних тестових проектів, всі відкриті в TestExplorer
2. 2 з 5 виконані правильно
3. 3 заявляючи, що не бігати зовсім
4. Проблема почалася після оновлення .net Framework

Розслідування

Оскільки всі пакети були оновлені під час оновлення .net Framework, я почав із відмінностей між робочими та не працюючими проектами. Перша підказка полягала в тому, що всі 3 проекти використовували: MSTest.TestAdapter та MSTest.TestFramework

Природно, я зайшов у консоль -> вихідна консоль -> тестовий випадок у VS 2019 та подивився вихід. Нічого корисного там немає.

Крок перший із рішення : Оновіть MSTest.TestAdapter і MSTest.TestFramework до версії 2.0.0

Крок другий з рішення : Тепер консоль виводу -> Тестовий вихідний вихід почав показувати один за одним, відсутні пакети та неправильні переадресації прив’язки

Крок третій із рішення : Вручну додайте відсутні пакети. Для мене це були

1. System.Runtime.Extentions
2. Система.Рефлексія
3. Можливо, ще щось, чого мені не вистачає

Крок 4 рішення : Видалено / виправлено несекретні переадресації прив’язки.

Сподіваюся, це допоможе комусь іншому.

Clean-Rebuild рішення працювало на мене.

Виникла така ж проблема після чистої установки VS 2019. Тести знайдені, але не виконуються з "Несподіваною помилкою". Виправлено встановленням x64 замість x86, який був обраний за замовчуванням.

Я виявив, що в проекті він не посилається на збірку Microsoft.VisualStudio.QualityTools.UnitTestFramework . Натомість він посилався на Microsoft.VisualStudio.TestPlatform.TestFramework та Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions . Коли я видалив ці дві посилання та додав посилання на збірку Microsoft.VisualStudio.QualityTools.UnitTestFramework, тести, які раніше були позначені синім знаком оклику, раптом активізувались і почали працювати.

У мене була ця проблема, і для мене це було викликано наявністю декількох тестових проектів з різними версіями:

• MSTest.TestAdapter
• MSTest.TestFramework

Консолідація пакетів «nuget» для проектів, щоб вони були однаковими, вирішили проблему для мене.

У моєму випадку це було тому, що в одному тестовому проекті в моєму рішенні встановлені нульові пакети MSTest.TestFramework та MSTest.TestAdapter, а інші - не. Ці пакети, очевидно, не вимагали для запуску тестів, поки один проект у рішенні не встановив їх.

Виправлено проблему, встановивши ці пакети на тестових проектах, у яких вони відсутні.

Для мене це вирішило оновлення пакетів нульових пакетів MS.Test

Встановлення Nunit3TestAdapterNuget вирішило цю проблему

Налаштування архітектури процесора для проектів AnyCPU у Test Explorer виправило мою проблему! Дивіться знімок екрана вище.

У моєму випадку у мене був async voidметод, і я його замінив async Task, тому тестовий запуск, як я очікував:

    [TestMethod]
    public async  void SendTest(){}

замінити :

    [TestMethod]
    public async  Task SendTest(){}

У мене були такі ж симптоми.

Переконайтеся, що встановлено правильне розширення Visual Studio через Інструменти - розширення та оновлення. У моєму випадку мені довелося встановити XUnit і Specflow з параметра Інтернет.

Потім очистіть розчин і відновіть його.

Якщо це все-таки не допомагає, очистіть тимчасовий каталог (знайдіть% temp% у пошуку в меню «Пуск» та видаліть увесь вміст у Temp)

А потім нарешті спробуйте видалити Resharper, що остаточно вирішило мою проблему.

Ось тестовий проект не був позначений для побудови:

Збірка -> Менеджер конфігурацій ... -> Перевірте збірку свого тестового проекту

Оскільки я потрапив сюди з такою помилкою, я публікую свою проблему / рішення:

Симптоми:

• Працюють не всі тести, але вони не залежать від проекту, лише деякі з них були виконані.
• Усі страчені були зеленими.
• Технологічний стек: ядро ​​dotnet / XUnit / FluentAssertions
• Усі тести виявлені та оновлені, якщо вони змінилися.
• Вибравши або виконавши "Не запущені тести" кілька разів, вони могли бути виконані.

Проблема:

У коді сталася помилка, яка кидає виняток всередині іншого потоку. Усі тестові твердження пройшли, але це скасувало виконання тесту. Я міг бачити помилку в "Тестовому виході" (NullException).

У мене були ті ж самі симптоми, в моєму випадку проблема була основною версією SDK для dotnet .

Проекти орієнтовані на 2.2, і він зміг створити за допомогою 3.0. Після встановлення новітньої версії 2.2 SDK їх вдалося запустити.

Ви можете переглянути помилку виводу вашого тестового бігуна, відкривши панель вихідних даних (перегляд -> вихід) та вибравши "тести" зі спадного меню "Показати вихід з"

Крім того, якщо у вас встановлений Resharper, ви можете відкрити тестовий файл та навести курсор миші на тестовий круг поруч із тестом, щоб отримати додаткову інформацію про помилку

Клацнувши, ви перейдете до вікна з більш детальною інформацією. Ви також можете відкрити це вікно, перейшовши до Розширення -> Переробник -> Windows -> Результати дослідження тестування блоку.

Спробували багато варіантів з Visual Studio 2019 Версія 16.4.6 і Microsoft.VisualStudio.TestTools.UnitTesting, але наразі єдиним способом успішного запуску тестів було виклик наступної команди в консолі

dotnet test

Тести виявлені в Test Explorer, але результат - "Не запустити".

Оновлення Visual Studio не допомогло.

Вирішили проблему з "Жоден тест не відповідає вказаному фільтру тестових примірників FullyQualifiedName", запустивши оновлення до останньої версії для наступних пакетів:

Microsoft.NET.Test.Sdk
MSTest.TestAdapter
MSTest.TestFramework

Для мене рішенням було змінити параметри тестування блоку Resharper Unit "Архітектура платформи за замовчуванням" на "x64"

Для мене перезапуск VS2017 не працював. Мені довелося очистити sln, тоді я знайшов файл із тестами, який не запускався та запускав лише цей файл. Після цього я все запустив, і це знову нормально працювало.

У мене були різні версії пакунків NUnit (3.11.0) та NunitTestAdapter (3.12.0). Коли я оновив NUnit до 3.12.0, Visual Studio проводив тести.

У моєму випадку вона працювала над оновленням MSTest пакетів нуд. Може відтворити цю проблему навіть на пустому проекті MSTest та оновленні відпрацьованих пакетів.

Для мене наявність властивості під назвою TestContext в базовому класі викликала таку поведінку. Наприклад:

[TestClass]
public abstract class TestClassBase
{
    protected object TestContext { get; private set; }
}

[TestClass]
public class TestClass : TestClassBase
{
    // This method not found
    [TestMethod]
    public void TestCase() {}
}

Я можу сказати з ваших атрибутів, що ви використовуєте MSTest. У мене була подібна проблема: мої тести відображалися в Тестовому Провіднику, але коли я спробував би їх запустити (вибираючи «Запустити все» або окремо вибравши їх), вони не будуть.

Моя проблема полягала в тому, що я створив блок тестового проекту вручну з порожнього проекту .NET Standard Class Library. Я встановив MSTest.TestFrameworkпакет NuGet, але не MSTest.TestAdapterпакет. Як тільки я встановив адаптерний пакет, вони бігли, як очікувалося.

Здається, це очевидно в ретроспективі, але коли ви створюєте блок-тестові проекти з шаблону, ви приймаєте ці речі як належне.

Варто зазначити, що інколи файли NUnit Test Adapter пошкоджуються у папці користувача C: \ Users [Користувач] \ AppData \ Local \ Temp \ VisualStudioTestExplorerExtensions \ NUnit3TestAdapter.3.8.0 / build / net35 / NUnit3.TestAdapter.dll в Windows 10 і що змушує тест-Explorer перестати працювати як слід.

Я використовую VS2019 з .Net 4.7. Я встановив розширення NUnit v3 і змінив налаштування тесту на використання X64. Мій тестовий проект модуля - будь-який процесор (працював би, якби я змінив його на x64) Тепер я можу налагоджувати код.

Ця проблема також спостерігається, коли запущений тестовий метод кидає StackOverflowException , завдяки чому тестовий бігун перериває тестовий запуск, в результаті чого виходить результат 0 tests run.

Щоб знайти винуватця та вирішити його, поставте крапку на початку методів оформлення TestInitialize та TestMethod , запустіть тестовий блок в режимі налагодження, продовжуйте переходити (F10), поки не буде викинуто виняток.