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

Процесс агента был остановлен на время выполнения теста.

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

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

Кто-нибудь еще видел такое поведение? Как я могу этого избежать?

редактировать

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

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

Прямо сейчас я не знаю, как это преодолеть.

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

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

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

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

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

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

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

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

Итак, мой файл .trx содержал:

   <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. Если в журнал событий не записывается информация, вероятно, это одна из других причин, перечисленных выше.

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

'QTAgent32.exe' (управляемый (v4.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, необработанное исключение обнаружено, сообщение через Watson: [сообщение об исключении]

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

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

Environment.Exit(0);

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

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

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

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

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

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

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

Надеюсь это поможет

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

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

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

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

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

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

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

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

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

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

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

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

Кстати: я использую WCFMock для подделки службы WCF, поэтому у меня есть «настоящие» модульные тесты для моей службы WCF.

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

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

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

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

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

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

Я смог определить причину моей проблемы, просмотрев Журналы Windows > Записи журнала приложений в средстве просмотра событий Windows . Ищите записи в то время, когда тест разбомбили. У меня была запись об ошибке, подобная приведенной ниже:

QTAgent32_40.exe, PID 10432, Thread 2) AgentProcess:CurrentDomain_UnhandledException: IsTerminating : System.NullReferenceException: Object reference not set to an instance of an object.
   at XXX.YYY.ZZZ.cs:line 660
   at XXX.YYY.AAA.Finalize() in C:\JenkinsSlave\workspace\XXX.YYY.AAA.cs:line 180

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

Для тех, кто задается этим старым вопросом и задается вопросом, что выбрасывается из их цепочек (ов), вот совет. Использование Task.Run (в отличие, скажем, от Thread.Start) будет гораздо более надежно сообщать об исключениях дочерних потоков. Короче вместо этого:

Thread t = new Thread(FunctionThatThrows);
t.Start();
t.Join();

Сделай это:

Task t = Task.Run(() => FunctionThatThrows());
t.Wait();

И ваши журналы ошибок должны быть намного полезнее.