Метод тестування є непереконливим: тест не виконувався. Помилка?

У мене є тестовий клас і нижче я розмістив зразок тесту з тестового класу

namespace AdminPortal.Tests.Controller_Test.Customer
{
    [TestClass]
    public class BusinessUnitControllerTests
    {
        private IBusinessUnitRepository _mockBusinessUnitRepository;
        private BusinessUnitController _controller;

        [TestInitialize]
        public void TestInitialize()
        {
            _mockBusinessUnitRepository = MockRepository.GenerateMock<IBusinessUnitRepository>();
            _controller = new BusinessUnitController(_mockBusinessUnitRepository);
        }

        [TestCleanup]
        public void TestCleanup()
        {
            _mockBusinessUnitRepository = null;

            _controller.Dispose();
            _controller = null;

        }

        #region Index Action Tests
        [TestMethod]
        public void Index_Action_Calls_GetAllBusinessUnit()
        {
            _mockBusinessUnitRepository.Stub(x => x.GetAllBusinessUnit());

            _controller.Index();

            _mockBusinessUnitRepository.AssertWasCalled(x=>x.GetAllBusinessUnit());
        }
    }
}

Коли я запускаю проект, я отримую наступний екран

Я перевірив посилання, і тестовий проект має посилання на основний проект. Будь-яка ідея, чому тест не проводиться, або каже, що вони були непереконливими?

Редагувати 1:

Я бачив повідомлення тут і змінив архітектуру процесора по замовчуванням налаштування моєї тестової в до X64 , але він по- , як і раніше не працює.

На всякий випадок, якщо жоден із перерахованих вище варіантів не працював ні для кого, я виправив свій примірник цієї помилки, помітивши пошкоджену запис у моєму App.Config через відсутність пакета нугів у тестовому проекті.

Для мене це було досить страшно, але я знайшов рішення для своєї справи принаймні:

Якщо ваш TestMethod асинхронізований, він не може бути недійсним. Це ОБОВ'ЯЗКОВО повернеться Завданням.

Сподіваюся, це комусь допоможе :)

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

Resharper => Options => Tools => Unit Testing

Мені просто довелося зняти прапорець "Асамблеї тіньової копії тестуються"

Це було питання Resharper. У параметрах Resharper-> Tools-> MSTEST я зняв галочку з Use Legacy Runner і тепер вона працює.

У мене була ця проблема, і вона виявилася такою ж, як ця проблема тут . Ця відповідь вирішила проблему для мене .

1. Зніміть прапорець "Створювати лише запуску проектів та залежності від запуску" (Опції -> Проекти та рішення -> Створити та запустити)
2. У програмі Configuration Manager переконайтесь, що і проект запуску, і тестовий проект встановили прапорець "Build".

Другий раз, коли я потрапив у цю проблему, це було пов’язано з амперсандом у файловому шляху до проекту, де проходять тести. Він чудово працює з тестовим бігуном ReSharper, але не з dotCover. Видаліть амперсанд з файлового контуру.

Це підтверджена помилка з dotCover.

Для мене просто очищення та відновлення розчину виправили це.

Для мене проблемою був пошкоджений XML-файл налаштувань NUnit / ReSharper (через несподіваний дефіцит живлення).

Щоб визначити помилку, я запустив Visual Studio з цією командою :

devenv.exe /ReSharper.LogFile C:\temp\resharper.log /ReSharper.LogLevel Verbose

Вивчення файлу виявило наступне виняток:

09:45:31.894 |W| UnitTestLaunch                | System.ApplicationException: Error loading settings file
System.ApplicationException: Error loading settings file ---> System.Xml.XmlException: Root element is missing.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
   at System.Xml.XmlDocument.Load(XmlReader reader)
   at System.Xml.XmlDocument.Load(String filename)
   at NUnit.Engine.Internal.SettingsStore.LoadSettings()
   --- End of inner exception stack trace ---
   at NUnit.Engine.Internal.SettingsStore.LoadSettings()
   at NUnit.Engine.Services.SettingsService.StartService()
   at NUnit.Engine.Services.ServiceManager.StartServices()
   at NUnit.Engine.TestEngine.Initialize()
   at NUnit.Engine.TestEngine.GetRunner(TestPackage package)
   at JetBrains.ReSharper.UnitTestRunner.nUnit30.BuiltInNUnitRunner.<>c__DisplayClass1.<RunTests>b__0()
   at JetBrains.ReSharper.UnitTestRunner.nUnit30.BuiltInNUnitRunner.WithExtensiveErrorHandling(IRemoteTaskServer server, Action action)

Зауважте, що це НЕ тест-проект app.config!

Швидко погуглити навколо визначили наступний файл в якості винуватця:

%LOCALAPPDATA%\NUnit\Nunit30Settings.xml

Він існував, але був порожнім. Видалення його та перезапуск Visual Studio вирішили проблему.

(Використання Visual Studio Professional 2017 v15.3.5 та ReSharper 2017.2.1).

Я зіткнувся з цією проблемою в оновленнях 3 порівняно з 2017 року за допомогою Resharper Ultimate 2017.2

Перезапуск vs або перезапуск машини не можуть допомогти.

Я вирішив проблему, очистивши кеш таким чином:

    Resharper ->options-> Environment ->click the button 'Clear caches'

Оновлення:

У правому верхньому куті тестового вікна є кнопка "помилка" (я знаходжу в Resharper 2018).

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

Щоб відстежувати корінь проблеми, запустіть Visual Studio у режимі журналу. У порівнянні з 2017 роком, виконайте команду:

      devenv /ReSharper.LogFile C:\temp\log\test_log.txt /ReSharper.LogLevel Verbose

Виконати тест.

Перегляньте файл журналу test_log.txt і знайдіть «помилку» у файлі.

Файл журналу - це чудова допомога в пошуку помилки, яку ви можете усунути, або ви можете надіслати проблему з файлом журналу команді технічної підтримки Resharper .

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

Оскільки R # не давав жодних деталей про те, чому справи провалюються, я вирішив спробувати вбудований тестовий бігун VS2013. Він зазнав точно такої ж поведінки, коли жоден з тестів не проходив. Однак, дивлячись у вікно виводу, я нарешті отримав повідомлення про помилку:

Виняток стався під час виклику виконавця "виконавець: // mstestadapter / v1": Посилання на об'єкт не встановлено для екземпляра об'єкта.

Це привело мене до чергової нитки на SO із рішенням. Повірте, я б ніколи не здогадувався, в чому проблема.

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

Я змінив це:

[assembly: AssemblyCulture("")] 

до цього:

[assembly: AssemblyCulture("en")]`. 

Це було все! Ось що незрозуміло зламало мої одиничні тести. Я все ще не розумію, чому, однак. Але принаймні все знову працює. Після того як я змінив цю зміну (тобто повернув культуру до ""), мої тести знову почали працювати.

Сподіваюся, що хтось там допомагає.

У моєму випадку [Test]методи були просто private. Сором

Моя проблема полягала в тому, що я встановив лише NUnit з nuget. Я не встановив NUnit3TestAdapter, який також був необхідний.

Install-Package NUnit3TestAdapter

У моєму випадку це була помилка, яку я зробив під час копіювання stringstring в app.config .. Я помістив його всередині тега configSections!

Мені потрібно було деякий час, щоб зрозуміти, що ... завдяки VS intellisense, хоча .. або це було переробити?

У мене було подібне питання. VS 2010, c # CLR 2 Nunit 2.5.7, просто збірка> чисте рішення від VS допомогло вирішити цю проблему

У моєму випадку я створив метод асинхронного тесту, який повернувся void. Повернення Taskзамість voidвирішеного питання.

Ви нещодавно додали залежність від DLL? ... як я

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

Причина була надзвичайно дурна: я щойно перед залежністю додав додаткову зовнішню DLL в підпроект, і головний додаток проекту дійсно побудував і працював правильно після зміни. Але мої одиничні тести знаходяться в сестринському проекті до основного додатку, і, таким чином, була занадто залежна від цього зміненого підпроекту, де викликали DLL ... все ж, час виконання тестового проекту не є головним додатком! Таким чином, зміна збірки для копіювання відсутньої DLL в тестовий каталог виконуваного виправила проблему.

Я використовую VS2013, ReSharper 9.1 з розширенням MSpec від ReSharper та Moq. Я зазнав таку саму "непереконливу" помилку.

Виявилося, що мій Mock з Moq не був ініціалізований, а лише оголошений. Оні ініціалізували всі тести знову запустилися.

У моєму випадку я отримав цю помилку через режим "Випуск", де збірка проекту UnitTests була просто відключена. Перемикання в режим «Налагодження» виправлено.

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

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

У моєму випадку всі тести в рамках деяких тестових проектів в рамках рішення не почали працювати після того, як я додав нові проекти. Використання VS 2017 з ReSharper 2017.1.2 тут.

Перш за все, переконайтеся, що ви не витрачаєте час, вважаючи, що ваша проблема пов'язана з ReSharper. Неважко припустити, що з ReSharper щось не так, якщо ви використовуєте його функції тестування одиниць, включаючи Unit Test Explorer . Відкрийте Visual Studio в Test Explorer , під Test меню і спробуйте запустити всі ». Додатковою перевагою цього є те , що вікно виведення з'явиться повідомлення про помилку , яке може вказувати вам в правильному напрямку. Якщо ви помітили , що той же самий набір тесту не запускаються, тоді можна з упевненістю припустити, що проблема пов’язана з Visual Studio, а не з ReSharper.

Я завершив видалення та повторне додавання однієї з платформ Active Active , будь-якого процесора , у програму Configuration Manager . Тим самим, після збереження змін та повторного відкриття рішення, всі тести знову почали працювати.

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

Для тих, хто відчуває цю проблему для мого тестового проекту .NET Core 2.0в Visual Studio 2017 Community (v15.3 3). Я також мав цю помилку за допомогою JetBrains ReSharper Ultimate 2017.2 Build 109.0.20170824.131346- є помилка, яку я опублікував.

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

• Видаліть це зі свого *.csprojфайлу:
• Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}"

Коли я це зробив - тести почали чудово працювати.

Я використовую VS2010, NUnit 2.6.3 (хоча внутрішньо ReSharper каже, що він використовує 2.6.2?), ReSharper 7.7.1 та NCrunch 2.5.0.12 і натрапляв на те саме "... тест є непереконливим ..." з NUnit, але NCrunch сказав, що все добре. Більшу частину сьогодні NUnit та NCrunch синхронізувались щодо того, які тести були задоволені та яким потрібен рефакторинг, тоді сталося щось, чого я досі не розумію, і деякий час NCrunch сказав, що я маю невдалі тести (але перейшовши через них, вони показали їм пас), то вирішив, що всі вони працюють, і NUnit почав скаржитися на всі мої тести, крім одного з тим же повідомленням "..тест непереконливий ...", який я знову зміг зробити один крок до проходу, хоча NUnit продовжував показати це як "непереконливий").

Я спробував кілька запропонованих вище пропозицій безрезультатно, і, нарешті, просто закрив VS2010 і знову відкрив рішення. Voila, тепер усі мої тести знову щасливі, і NCrunch & NUnit знову повідомляють про ті самі результати. На жаль, я не маю уявлення, що змінилося, щоб змусити їх синхронізуватись, але закриття та повторне відкриття VS2010, схоже, виправили це.

Можливо, хтось інший зіткнеться з цим і зможе скористатися цим простим (якщо в кінцевому рахунку незадовільним, оскільки ви не знаєте, що таке справжнє виправлення).

У мене був цей самий випуск. Винувателем стала зовнішня посилання, яка не сумісна з моїми налаштуваннями проекту. Щоб вирішити, я клацнув правою кнопкою миші проект-> властивості-> збір-> ціль платформи-> змінити з будь-якого процесора на x86.

Конкретний * .dll, з яким я працював, був System.Data.SQLite. Цей конкретний * .dll жорстко кодується для 32-бітної роботи. Параметр "Будь-який процесор" намагався завантажити його як 64 біт.

Моє рішення:

У NUnit 3.2.0 є деякі проблеми з Resharper - оновлення до 2.6.4:

update-package nunit -version 2.6.4

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

Викликаний відсутнім (не пошкодженим) файлом App.Config. Додавання нового (Додати -> Новий елемент ... -> Файл конфігурації програми) виправлено.

У мене була така ж проблема. Вона була пов'язана з версією сумісності між NUnit 3.5 та Resharper 9.2, оскільки вона була вирішена шляхом пониження рівня з NUnit 3.5 до 2.6.4. Це працювало для мене. Щасти.

Якщо ви використовуєте xUnit, я вирішив проблему встановлення xunit.running.visualstudioпакета. (наразі використовується xUnit 2.3.1та VS17 Enterprise 15.3.5)

У мене виникли ті ж проблеми, щоб запустити будь-який тест за допомогою NUnit Framework. Visual Studio 2017 15.5.6 "Непереконливо: тест не запускається"

ReSharper Ultimate 2017.3.3 збірка 111.0.20180302.65130

РІШЕННЯ Додавання залежності проекту до Microsoft.NET.Test.Sdk

Для тих, хто поспішає з тестовим виконанням, мені довелося використовувати тест-дослідник VS 2017 для запуску тестів;

Ця помилка сталася з Visual Studio 2017 та перезавантажуваною версією 2018.2.3, але виправлення стосується версій Visual Studio 2019 до.

Виправити тести, які працюють в Resharper, було просто оновити до останньої версії Resharper (2019.2.1) на момент написання.

У мене було саме таке питання, і нічого не допомогло.

врешті-решт я побачив, що у мене невідповідність просторів імен одиничного проекту та тестового проекту.

Простір імен мого одиничного проекту - unit.project, а тестовий проект був названий unit.project.tests, але простір імен тесту за замовчуванням був таким самим, як одиниця, обидва - unit.project.

Після оновлення просторів імен, щоб вони були різними (по одному простору імен для кожного проекту), все працювало!