У меня есть тестовый класс, и ниже я разместил образец теста из тестового класса
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, но он все еще не работает.
c#
asp.net-mvc
asp.net-mvc-4
unit-testing
resharper
Cybercop
источник
источник
Ответы:
На всякий случай, если ни один из перечисленных выше вариантов не работал ни для кого, я исправил свой экземпляр этой ошибки, заметив поврежденную запись в моем App.Config из-за отсутствия пакета nuget в тестовом проекте.
источник
<configSections>
.Для меня это было довольно неприятно, но я нашел решение по крайней мере для моего случая:
Если ваш TestMethod является асинхронным, он не может быть аннулирован. Он ДОЛЖЕН вернуть задание.
Надеюсь, это поможет кому-то :)
источник
У меня была такая же проблема с resharper, и я исправил эту ошибку, изменив параметр:
Resharper => Параметры => Инструменты => Модульное тестирование
Мне просто пришлось снять флажок «Тестируемые сборки теневого копирования»
источник
Это была проблема Решарпера. В опциях Resharper-> Tools-> MSTEST я снял флажок Use Legacy Runner, и теперь он работает.
источник
У меня была эта проблема, и она оказалась такой же, как эта проблема здесь . Этот ответ решил проблему для меня .
Во второй раз, когда я столкнулся с этой проблемой, это произошло из-за амперсанда в пути к файлу проекта, в котором находятся тесты. Он отлично работает с тестером ReSharper, но не с dotCover. Удалить амперсанд из пути к файлу.
Это подтвержденная ошибка с dotCover.
источник
Для меня просто очистить и восстановить решение исправило это.
источник
Для меня проблема была в поврежденном XML-файле настроек NUnit / ReSharper (из-за неожиданного дефицита питания).
Чтобы определить ошибку, я запустил Visual Studio с помощью этой команды :
Изучение файла выявило следующее исключение:
Обратите внимание, что это НЕ app.config тестового проекта!
Быстро погуглить вокруг определили следующий файл в качестве виновника:
Он существовал, но был пуст. Удаление и перезапуск Visual Studio решили проблему.
(Использование Visual Studio Professional 2017 v15.3.5 и ReSharper 2017.2.1).
источник
Я столкнулся с этой проблемой в обновлении 3 против 2017 с Resharper Ultimate 2017.2
Перезапуск или перезагрузка компьютера не может помочь.
Я решил проблему, очистив кэш следующим образом:
Обновить:
В правом верхнем углу тестового окна есть кнопка «ошибка» (я нахожу в Resharper 2018).
Если вы нажмете кнопку ошибки, появится сообщение об ошибке, которое может помочь в решении проблемы.
Чтобы отследить причину проблемы, запустите Visual Studio в режиме журнала. В vs 2017 запустите команду:
Запустите тест.
Просмотрите файл журнала test_log.txt и найдите в нем «error».
Файл журнала - отличная помощь для поиска ошибки, которую вы можете устранить, или вы можете отправить проблему с файлом журнала в службу технической поддержки Resharper .
источник
Я только что исправил эту проблему. Однако ни одно из решений в этой теме не сработало. Вот что я сделал ...
Поскольку R # не давал никаких подробностей о том, почему что-то не так, я решил попробовать встроенный тестер VS2013. Он испытал точно такое же поведение, когда ни один из тестов не проводился. Однако, глядя в окно вывода, я наконец-то получил сообщение об ошибке:
Это привело меня к другому потоку на SO с решением. Поверьте мне, я бы никогда не догадался, в чем проблема.
Недавно я сделал несколько изменений в файле AssemblyInfo.cs при создании пакета NuGet. Одно из изменений, включая указание значения культуры сборки "en".
Я изменил это:
к этому:
Вот и все! Вот что необъяснимо сломало мои юнит-тесты. Я все еще не понимаю, почему, однако. Но, по крайней мере, все снова работает. После того, как я отменил это изменение (то есть вернул культуру на ""), мои тесты снова начали выполняться.
Надеюсь, это поможет кому-то там.
источник
В моем случае
[Test]
методы были простоprivate
. срамисточник
Моя проблема была в том, что я только установил NUnit с nuget. Я не установил NUnit3TestAdapter, который также был необходим.
источник
В моем случае это была ошибка, которую я сделал при копировании строки подключения в app.config. Я поместил ее в тег configSections!
Мне потребовалось время, чтобы понять, что ... спасибо VS intellisense, хотя .. или это было резче?
источник
У меня была похожая проблема. VS 2010, c # CLR 2 Nunit 2.5.7, просто собрать> чистое решение от VS помогло решить эту проблему
источник
В моем случае я создал метод асинхронного теста, который вернулся
void
. ВозвращениеTask
вместоvoid
решенного вопроса.источник
Вы недавно добавили какую-либо зависимость от DLL? ... как я
Я просто столкнулся с той же проблемой, и мне было очень неприятно не получить никакой подсказки в окне вывода теста или где-либо еще практично.
Причина была чрезвычайно глупой: я просто добавил накануне зависимость в дополнительную внешнюю DLL в подпроекте, и основной проект App действительно был создан и работал правильно после изменения. Но мои модульные тесты находятся в дочернем проекте для основного приложения, и, таким образом, они также зависели от этого измененного подпроекта, в котором была вызвана DLL ... но место выполнения тестового проекта не совпадает с основным приложением! Таким образом, изменение сборки для копирования отсутствующей DLL-библиотеки в каталог времени выполнения теста устранило проблему.
источник
Я использую VS2013, ReSharper 9.1 с расширением MSpec от ReSharper и Moq. Я испытал ту же "неокончательную" ошибку.
Оказалось, что один из моих Mock's от Moq не был инициализирован, только объявлен. Все инициализировались, все тесты запускались снова.
источник
В моем случае я получил эту ошибку из-за режима Release, когда сборка проекта UnitTests была просто отключена. Переключение обратно в режим «Отладка» исправило это.
Удивительно, что ReSharper не может ничего сказать, если вообще не может найти библиотеку UnitTests. Серьезно, это позор;)
Надеюсь, это кому-нибудь поможет
источник
В моем случае все тесты в рамках некоторых тестовых проектов в рамках решения не запускались после добавления новых проектов. Использование VS 2017 с ReSharper 2017.1.2 здесь.
Прежде всего, убедитесь, что вы не тратите время, предполагая, что ваша проблема связана с ReSharper. Легко предположить, что с ReSharper что-то не так, если вы используете его функции модульного тестирования, включая Unit Test Explorer . Откройте Visual Studio в Test Explorer , под Test меню и попробуйте запустить все ». Дополнительным преимуществом этого является то , что окно вывода появится сообщение об ошибке , которое может указывать вам в правильном направлении. Если вы заметили , что тот же самый набор теста не запускаются, тогда можно предположить, что проблема связана с Visual Studio, а не с ReSharper.
В итоге я удалил и снова добавил одну из платформ Active Solution , Any CPU , в 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 и снова открыл решение. Вуаля, теперь все мои тесты снова счастливы, и NCrunch & NUnit сообщают те же результаты снова. К сожалению, я понятия не имею, что изменилось, чтобы заставить их выйти из синхронизации, но закрытие и повторное открытие VS2010, кажется, исправило это.
Может быть, кто-то еще столкнется с этим и сможет использовать это простое (если в конечном итоге неудовлетворительное, так как вы не знаете, каково реальное решение) решение.
источник
У меня была такая же проблема. Виновником была внешняя ссылка, несовместимая с настройками сборки моего проекта. Чтобы решить, я щелкнул правой кнопкой мыши на проекте-> свойства-> build-> Platform Target-> изменить с любого процессора на x86.
Конкретной * .dll, с которой я работал, был System.Data.SQLite. Этот конкретный * .dll жестко запрограммирован для 32-битной операции. Параметр «Любой процессор» пытался загрузить его как 64-битный.
источник
Мое решение:
В NUnit 3.2.0 есть некоторые проблемы с Resharper - понижение до 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 Build 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.
Как только я обновил пространства имен, чтобы они были разными (одно пространство имен для каждого проекта), все работало!
источник