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

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

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

public void GetThingy()
{
    this.GetThingy();
}

Это, конечно, бесконечная рекурсия, и вызвал StackOverflowException (я думаю). Это вызвало страх: "процесс агента был остановлен во время выполнения теста."

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

я смог найти источник моей проблемы, посмотрев в файле результатов теста (/TestResults/*.trx) он предоставил полную информацию об исключении, которое произошло в фоновом потоке, и как только я разрешил это исключение, "обработанный агент остановился..."ошибка ушла.

в моем случае я непреднамеренно запускал графический интерфейс в своем модульном тесте, что в конечном итоге вызвало систему.ComponentModel.Необходимо создать исключение InvalidAsynchronousStateException.

Так что мой .трансивер файл содержал:

   <RunInfo computerName="DT-1202" outcome="Error" timestamp="2013-07-29T13:52:11.2647907-04:00">
    <Text>One of the background threads threw exception: 
System.ComponentModel.InvalidAsynchronousStateException: An error occurred invoking the method.  The destination thread no longer exists.
at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
...
</Text>
  </RunInfo>

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

это сообщение обычно генерируется при сбое процесса тестирования и может произойти при наличии необработанного исключения в фоновом потоке, переполнении стека или явном вызове Process.GetCurrentProcess().Kill() или Environment.Exit. Другой возможной причиной является нарушение прав доступа в неуправляемом коде.

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

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

асинхронное исключение может иметь произошло

во время моей тестовой установки я создаю объект, который ставит рабочий поток в очередь в пуле потоков. Если я запускаю отладку достаточно быстро, мой код проходит.

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

Если рабочий поток запускается и имеет ошибку после начала теста, то я получаю результат : ошибка - процесс агента был остановлен во время выполнения теста.

важно отметить: это компонент, который я использую на протяжении нескольких моих тестов. Если платформа тестирования обнаруживает слишком много таких ошибок, она прерывает Остальные тесты.

надеюсь, что это помогает

я столкнулся с той же проблемой и решил ее при удалении

Environment.Exit(0);

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

в моем случае решение было решено путем проверки Окно Вывода.

' QTAgent32.exe '(управляемый (В4.0.30319)): загружен 'C:\TestResults\bdewey_XXXXXX072 2011-01-11 17_00_40\Out\MyCode.dll', Символы загружены. E, 9024, 9, 2011/01/11, 17:00:46.827, XXXXX072\QTAgent32.exe, необработанный Исключение поймано, отчетность через Уотсон: [сообщение об исключении]

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

У меня была та же проблема, и она была вызвана финализатором для неуправляемого ресурса (файловый писатель, который по какой-то причине не был правильно удален).

после обертывания кода финализатора в try-catch, который проглатывает исключение, проблема исчезла. Я не рекомендую глотать такие исключения, поэтому, очевидно, было бы разумно выяснить, почему это исключение происходит в первую очередь.

У меня это происходило в нечетных случаях, и виновник почти всегда оказывается потоком.

Как ни странно, все тесты будут работать нормально на машинах разработки, а затем случайным образом сбой на серверах сборки.

при ближайшем рассмотрении оказалось, что, хотя тесты были перечислены как пройденные на коробках dev, были брошены исключения. Исключения были брошены на отдельный поток, который не был подобран как ошибка.

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

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

Я добавил блоки try/catch к описателю ~ClassName () {}, которые были определены в любом классе, участвующем в моих тестах. Это исправило проблему для меня.

~MyClass()
{
    try
    {
        // Some Code
    }
    catch (Exception e)
    {
        // Log the exception so it's not totally hidden
        // Console.WriteLine(e.ToString());
    }
}

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

Это очень помогает отследить ошибку!

в моем случае у меня были некоторые модульные тесты для WCF-службы. Эта служба WCF запускала 2 таймера.
Эти таймеры вызывали побочные эффекты.
-- >Я отключаю эти таймеры по умолчанию, и все в порядке!

кстати: я использую WCFMock чтобы подделать службу WCF, поэтому у меня есть "настоящие" модульные тесты вокруг моей службы WCF

эта ошибка была вызвана Финализатором и для меня.
Финализатор actaully вызывал какой-то код БД, который не был высмеян. Мне потребовалось некоторое время, чтобы найти его, поскольку это был не класс, который я написал, и ссылка на него была похоронена довольно глубоко.

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

Я подозреваю, что проблема может быть в том, что DLL из моего другого проекта из проекта Visual Studio 2012, и я запускаю свои тесты в проекте VS2010 и/или, возможно, что UnitTestFramwork версии dll из 2-х проектов не совпадают.

проблема также может быть вызвана исключением или Stackoverflow в конструкторе TestClass.

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

Если все ваши тесты прерываются, как описано в OP, причиной может быть неправильная конфигурация проекта. В моем случае целевой фреймворк был установлен на .NET Framework 3.5. Установка его на более высокую версию через страницу свойств проекта (tab приложение) решен вопрос.