Visual studio не запускается тест

Обновлено: 07.07.2024

Я наблюдаю очень странное поведение тестов NUnit в VS2019, где то же решение отлично работает в VS2017. В моей душе есть несколько тестовых проектов NUnit.

В VS2017 с установленным расширением NUnit Runner я вижу все свои тесты в окне обозревателя тестов, и кнопка "запустить все" будет работать и запускать все тесты. Некоторые разработчики в моей организации используют Resharper вместо расширения NUnit, и это тоже работает.

Я прекратил использовать Resharper, потому что по мере того, как VS вводит больше функций, Resharper делает его настолько медленным, что VS становится непригодным для использования.

В VS2019 в окне Test Explorer будут отображаться все мои модульные тесты (даже без установленного расширения NUnit). Если я нажму "запустить все", тесты не будут запускаться, а в окне вывода будет указано, что обнаружено 0 тестов. Коллеги сказали, что Resharper будет запускать все тесты без проблем. Если я щелкну правой кнопкой мыши один тестовый проект и запускаю только эти тесты, некоторые проекты будут запускать тесты, но не все.

Для некоторых проектов я попытался установить пакет nuget NUnit3TestAdapater, и это позволит VS2019 запустить тест этого проекта, если выбран только этот проект. Это работает не для всех проектов, и не для всех проектов.

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

Решение оказалось комбинацией двух вещей.

Использование пакета NuGet для тестового адаптера вместо использования расширения VSIX. Кажется, что для этого фрагмента все, что требуется, - это чтобы хотя бы один проект в вашем решении ссылался на него. Если на него ссылается хотя бы один проект, все тестовые проекты могут быть запущены. (Для меня это имеет смысл, поскольку он более совместим с инструментами сборки за пределами Visual Studio.)

Ура за критические изменения!

В итоге я установил в свой тестовый проект три пакета:

Однако включение или выключение автоматического обнаружения тестов ничего не изменило.

Надеюсь, это кому-нибудь поможет.

У меня была такая же проблема, и я решил ее, проверив журнал.

В Tools-> Options-> Test-> General установите для уровня ведения журнала значение «Диагностика». Это приведет к появлению дополнительных результатов на панели вывода тестов окна вывода.

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

Выполните сборку проекта и убедитесь в том, что в разделе Сервис > Параметры > Тест включено обнаружение на основе сборок.

Обозреватель тестов, символ плюса (+)

Что означает символ "+" (плюс) в верхней строке обозревателя тестов?

Символ "+" (плюс) означает, что после сборки и выполнения обнаружения на основе сборок могут быть обнаружены дополнительные тесты. Этот символ отображается, если в проекте обнаружены динамически определяемые тесты.

Обнаружение на основе сборок

Обнаружение на основе сборок перестало работать в моем проекте. Как включить его снова?

Выберите пункты Сервис > Параметры > Тест и установите флажок Также вести обнаружение тестов в сборках после их создания.

Обнаружение тестов в режиме реального времени

Теперь тесты появляются в обозревателе тестов сразу при вводе кода, не дожидаясь сборки. Что изменилось?

Эта возможность называется Обнаружение тестов в реальном времени. На основе анализатора Roslyn она обнаруживает тесты и переносит данные о них в обозреватель тестов прямо в режиме реального времени, еще до сборки проекта. Дополнительные сведения об алгоритме обнаружения для динамически определяемых тестов, например с использованием теорий или пользовательских признаков, см. в разделе Обнаружение динамических тестов.

Совместимость с обнаружением тестов в реальном времени

Какие языки и платформы тестирования поддерживают обнаружение тестов в реальном времени?

Журналы обозревателя тестов

Как можно включить журналы для обозревателя тестов?

Откройте Сервис > Параметры > Тест и найдите раздел "Ведение журнала".

Обнаружение тестов UWP

Почему мои тесты в проектах UWP не обнаруживаются без развертывания приложения?

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

Сортировка в обозревателе тестов

Как работает сортировка результатов тестирования в иерархическом представлении?

Иерархическое представление сортирует тесты по алфавиту, а не по результату. Предыдущие параметры группирования сортировали результаты тестов по результату, а затем по алфавиту. Вы по-прежнему можете включить сортировку по результату, щелкнув правой кнопкой мыши заголовок столбца в обозревателе тестов, включив столбец "Состояние", а затем щелкнув заголовок столбца "Состояние", чтобы применить сортировку по этому столбцу. Вы можете оставить отзыв о такой схеме сортировки в этом вопросе в GitHub.

Иерархическое представление в обозревателе тестов

В иерархическом представлении возле группирований родительских узлов есть значки пройденных, непройденных, пропущенных и невыполненных тестов. Что означают эти значки?

Значки возле группирований проектов, пространств имен и классов указывают на состояние тестов в определенном группировании. См. приведенную ниже таблицу.

Поиск по пути к файлу

В поле поиска обозревателя тестов исчез фильтр "Путь к файлу".

Фильтр "Путь к файлу" в поле поиска обозревателя тестов удален в Visual Studio 2017 версии 15.7. Эта функция используется мало. Чтобы обозреватель тестов получал методы теста быстрее, ее можно исключить. Если это изменение прерывает ваш поток разработки, сообщите нам, отправив отзыв в сообщество разработчиков.

Удаление недокументированных интерфейсов

Некоторые интерфейсы API, относящиеся к тесту, отсутствуют в Visual Studio 2019. Что изменилось?

В Visual Studio 2019 будут удалены некоторые API окон тестов, которые были ранее помечены как общедоступные, но никогда не были официально задокументированы. Они были помечены как "нерекомендуемые" в Visual Studio 2017, чтобы заранее предупредить группы обслуживания расширений. Насколько нам известно, с этими API-интерфейсами работала и была связана лишь незначительная часть расширений. К ним относятся IGroupByProvider , IGroupByProvider<T> , KeyComparer , ISearchFilter , ISearchFilterToken , ISearchToken и SearchFilterTokenType . Если это изменение влияет на ваше расширение, сообщите нам, отправив сведения об ошибке в сообщество разработчиков.

Ссылка NuGet для адаптера теста

В Visual Studio 2017 версии 15.8 тесты обнаруживаются, но не выполняются.

Если вы используете адаптер теста NUnit 2 и не можете перейти на адаптер теста NUnit 3, можно отключить это новое поведение обнаружения в версии Visual Studio 15.8 в разделе Сервис > Параметры > Тест.

UWP TestContainer не найден

Мои тесты UWP больше не выполняются в Visual Studio 2017 версии 15.7 и более поздних версий.

Последние тестовые проекты UWP указывают свойство сборки платформы тестирования, что позволяет повысить производительность при обнаружении тестовых приложений. Если у вас есть тестовый проект UWP, который был инициализирован в версии Visual Studio ниже 15.7, в разделе Вывод > Тесты вы можете увидеть следующую ошибку.

System.AggregateException: произошла одна или несколько ошибок. ---> System.InvalidOperationException: не удалось найти следующий объект TestContainer <> в Microsoft.VisualStudio.TestWindow.Controller.TestContainerProvider <GetTestContainerAsync>d__61.MoveNext()

Обновите свойство сборки тестового проекта, используя следующий код.

Обновите версию пакета SDK TestPlatform, используя следующий код.

Использование предварительных версий функций

В Visual Studio 2019 включить предварительные версии функции в разделе "Инструменты" > "Параметры" > "Среда" > "Предварительные версии функций" .

Использование флагов функций

Как включить флаги функций, чтобы испытать новые возможности тестирования?

Флаги функций позволяют предоставить экспериментальные или незавершенные части продукта энтузиастам, которые готовы опробовать новые функции до официального выпуска и прислать отзыв о них. Их применение может нарушить работу интегрированной среды разработки. Используйте их только в безопасных средах разработки, например на виртуальных машинах. Использование флагов функций всегда сопряжено с некоторым риском и для них не предоставляются гарантии. Экспериментальные функции вы можете включить с помощью расширения флагов функций или в командной строке разработчика.

Чтобы включить флаг функции через командную строку разработчика Visual Studio, используйте следующую команду. Укажите в ней путь к локальной папке, где установлена среда Visual Studio, и раздел реестра для нужного флага функции.

Этой же командой можно отключить флаг, изменив значение после dword c 1 на 0.

когда я запускаю проект, я получаю следующее окно

Я проверил ссылки и тестовый проект имеет ссылку на основной проект. Есть идеи, почему тест не работает или говорит, что они были неубедительными?

Edit 1:

на всякий случай, если ни один из вышеперечисленных вариантов не работал ни для кого, я исправил свой экземпляр этой ошибки, заметив поврежденную запись в моем приложении.Config из-за отсутствия пакета nuget в тестовом проекте.

для меня это было довольно неприятно, но я нашел решение для моего случая по крайней мере:

Если ваш TestMethod является асинхронным, он не может быть пустоты. Он должен вернуть задачу.

надеюсь, это поможет кому-то:)

У меня была такая же проблема с resharper, и я исправил эту ошибку, изменив опцию:

Resharper => Options => Tools => Модульное Тестирование

Мне просто нужно было снять флажок "тестируемые сборки теневого копирования"

Это была проблема Resharper. В параметрах Resharper - >Tools - >MSTEST я снял флажок Использовать Legacy Runner, и теперь он работает.

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

снимите флажок " только создавать проекты запуска и зависимости от запуска "(параметры -> проекты и решения -> сборка и запуск)
в Configuration Manager убедитесь, что и начальный проект, и тестовый проект "Build" проверены.

в во второй раз я попал в эту проблему из-за амперсанда в пути к файлу проекта, где находятся тесты. Он отлично работает с тестовым бегуном ReSharper, но не dotCover. Удалите амперсанд из пути к файлу.

для меня просто очистка и восстановление решения исправили его.

для меня, проблема была поврежден NUnit / ReSharper настройки XML-файла (из-за неожиданной нехватки энергии).

чтобы определить ошибку, я начал Visual Studio с эта команда:

изучение файла показало следующее исключение:

обратите внимание, что это не приложение тестового проекта.конфиг!

A быстрый поиск примерно определили следующий файл в качестве виновника:

(С помощью Visual Studio Professional 2017 v15.3.5 и ReSharper 2017.2.1).

Я только что исправил эту проблему. Однако ни одно из решений в этом потоке не сработало. Вот что я сделал.

исключение при вызове исполнителя 'исполнитель:/ / mstestadapter / v1': Ссылка на объект не указывает на экземпляр объекта.

это привело меня к еще одна нить на SO С раствором. Поверьте, я бы никогда не догадался, в чем дело.

недавно я внес несколько изменений в AssemblyInfo.cs-файл при создании пакета NuGet. Одно из изменений, включая указание значения культуры сборки "en".

вот оно что! Это то, что необъяснимо сломало мои модульные тесты.

надеюсь, что это поможет кому-то там.

в моем случае это была ошибка, которую я сделал при копировании connectionstring в приложении.конфиг.. Я поместил его в тег configSections!

Мне потребовалось некоторое время, чтобы понять это. хотя спасибо VS intellisense.. или это был Решарпер?

в моем случае я создал метод асинхронного теста, который вернул void . Возвращаясь из Task вместо void решается вопрос.

в моем случае [Test] методы были просто private . Ш-А-я

вы недавно добавили зависимость от DLL? . как я!--1-->

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

причина была чрезвычайно глупой: я просто добавил накануне зависимость к дополнительной внешней DLL в подпроекте, и основное приложение проекта действительно построено и запущено правильно после изменения. Но мои модульные тесты находятся в сестринском проекте для основного приложения и, таким образом, тоже зависимость от этого измененного подпроекта, в котором была вызвана DLL. тем не менее, место выполнения тестового проекта не является основным приложением! Поэтому изменение сборки для копирования отсутствующей DLL в каталог тестовой среды выполнения исправило проблему.

Я использую VS2013, ReSharper 9.1 с расширением MSpec от ReSharper и Moq. Я испытал ту же "неубедительную" ошибку.

оказалось, что один из моих макетов от Moq не был инициализирован, только объявлен. Те инициализировали все тесты снова.

в моем случае я получил эту ошибку из-за режима "Release", где сборка проекта UnitTests была просто отключена. Переключение обратно в режим "Debug" исправило это.

Это действительно удивительно, что ReSharper ничего не может сказать, если он не может найти библиотеку UnitTests вообще. Серьезно, это позор;)

надеюсь, что это поможет кому-то

в моем случае мой метод тестирования был частным, я изменил его на публичный, и он работал.

в моем случае, все тесты в некоторых тестовых проектах в решении не запускались после добавления новых проектов. Использование VS 2017 с ReSharper 2017.1.2 здесь.

Я закончил удаление и повторное добавление одного из платформа активных решений, любой ЦП, в настройки Менеджер!--6-->. Таким образом, после сохранения изменений и повторного решения, все тесты снова начали бежать.

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

Я попробовал несколько предложений выше безрезультатно, и, наконец, просто закрыл VS2010 и снова открыл решение. Вуаля, теперь все мои тесты снова счастливы, и NCrunch & NUnit сообщают то же самое результаты снова. К сожалению, я понятия не имею, что изменилось, чтобы заставить их выйти из синхронизации, но закрытие и повторное открытие VS2010, похоже, исправили его.

возможно, кто-то еще столкнется с этим и сможет использовать это простое (если в конечном итоге неудовлетворительное, так как вы не знаете, что такое реальное исправление) решение.

JetBrains посоветовал создать новый тестовый проект с нуля, чтобы воспроизвести его. Когда я сделал это и получил тесты, работающие нормально, я нашел причину, вызывающую проблему:

когда я это сделал-тесты начали работать нормально.

моя проблема заключалась в том, что я установил NUnit только с nuget. Я не установил NUnit3TestAdapter, который также был необходим.

У меня была точно такая же проблема и ничего не помогало.

в конце концов я увидел, что у меня есть несоответствие в моих пространствах имен unit project и unit test project.

пространство имен моего единичного проекта-unit.проект и тестовый проект был назван блок.проект.тесты, но пространство имен по умолчанию теста было таким же, как и единица, оба были единицей.проект.

Как только я обновил пространства имен, чтобы быть разными (одно пространство имен для каждого проекта) все сработало!

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

У меня была такая же ошибка в VS2013 и Resharper9. Проблема была в том, что я забыл аннотировать метод тестирования с помощью [Test] :) Надеюсь, это поможет кому-нибудь

У меня была такая же проблема. Виновником была внешняя ссылка, не совместимая с моими настройками сборки проекта. Чтобы решить эту проблему, я щелкнул правой кнопкой мыши на project->properties->build->Platform Target-> change from Any CPU to x86.

в частности *.dll, с которой я работал, была системой.Данные.Базы данных SQLite. Именно это *.dll жестко закодирован для 32-битной операции. Параметр "любой процессор" попытался загрузить его как 64 бит.

У меня была точно такая же проблема, никакие тесты не запускались в моем тестовом проекте. Как это случилось, у меня была неправильная конфигурация, выбранная при запуске тестов. Изменение его обратно в Debug исправило проблемы.

в моем случае я ссылался на 2 проекта из моего unittestproject. Оба ссылочных проекта использовали dll с тем же именем, но с другой версией.

Я не заметил этого в Visual Studio. Я заметил ошибку в Eventviewer.

чтобы решить эту проблему, я использовал bindingRedirect в приложение.конфигурация unittestproject для исправления dll-версии.

IWebDriver driver = new FirefoxDriver();

А вы все библиотеки подключили, необходимые для корректного запуска?

IWebDriver driver = new FirefoxDriver();

ЗАметил, что во всех туториалах нужно ещё подключать библиотеки:
Ionic.Zip.dll
Newtonsoft.Json.dll
nmock.dll

Вот у меня их нету в скачанных папках NUnit и Selenium WebDriver. И где их достать тогда, если их нет на официальных сайтах?

ЗАметил, что во всех туториалах нужно ещё подключать библиотеки:
Ionic.Zip.dll
Newtonsoft.Json.dll
nmock.dll

Вы пользуетесь Visual Studio?

К сожалению опять нет, всё равно та же самая ошибка:

Прикрепленные файлы

using System;
using System.Text;
using System.Text.RegularExpressions;
using System.Threading;
using NUnit.Framework;
using OpenQA.Selenium;
using OpenQA.Selenium.Firefox;
using OpenQA.Selenium.Support.UI;

namespace SeleniumTests
[TestFixture]
public class Test1
private IWebDriver driver;
private StringBuilder verificationErrors;
private string baseURL;
private bool acceptNextAlert = true;

[TearDown]
public void TeardownTest()
try
driver.Quit();
>
catch (Exception)
// Ignore errors if unable to close the browser
>
Assert.AreEqual("", verificationErrors.ToString());
>

private string CloseAlertAndGetItsText() try IAlert alert = driver.SwitchTo().Alert();
if (acceptNextAlert) alert.Accept();
> else alert.Dismiss();
>
return alert.Text;
> finally acceptNextAlert = true;
>
>
>
>

Но в коде нету смысла, даже если просто написать одну единственную строку

Читайте также: