Erro do executor de teste do VS 2010 “O processo do agente foi interrompido enquanto o teste estava em execução.”


101

No Visual Studio 2010, tenho vários testes de unidade. Quando executo vários testes ao mesmo tempo usando listas de teste, às vezes recebo o seguinte erro para um ou mais dos testes:

O processo do agente foi interrompido durante a execução do teste.

Nunca é o mesmo teste falhando, e se eu tentar executá-lo novamente, ele será bem-sucedido.

Encontrei este relatório de bug no Connect , que parece ser o mesmo problema, mas não oferece uma solução.

Alguém mais viu esse comportamento? Como posso evitar isso?

Editar

Ainda estou enfrentando esse bug, assim como muitos dos meus colegas na mesma configuração de software / hardware. Avaliei as respostas até agora, mas elas não resolvem o problema. Estou começando uma recompensa para uma solução para este problema.


Estou recebendo a mesma coisa. Estou investigando, mas nenhuma solução até agora
Marcos

Alguma novidade sobre isso? O mesmo problema aqui ...
Peter Gfader

@Peter, veja meu comentário abaixo da resposta aceita. Essa foi a minha solução, mas não sei se o seu problema é semelhante.
driis

Tive o mesmo comportamento com uma exceção não detectada. A exceção estava visível para mim quando executei o Visual Studio no servidor de compilação e obtive uma janela Assert. Por causa da janela de assert, o teste não pôde continuar.

Respostas:


41

Acabei de experimentar um problema semelhante: alguns testes falham e são diferentes em diferentes execuções de teste. Não sei exatamente por que isso acontece, mas começou a ocorrer quando adicionei um finalizador a uma de minhas aulas. Quando eu desabilito o finalizador - o problema desaparece. Quando ligo o finalizador - o problema volta.

No momento, não sei como superar isso.


16
OBRIGADO - essa resposta me leva à solução. Tenho apenas um finalizador em alguns tipos e, com certeza, removê-los também removeu o problema. Após uma investigação mais aprofundada, descobri um bug sutil em um finalizador, que ocorria apenas quando uma exceção era lançada no construtor e o finalizador tentava finalizar um objeto que não estava totalmente construído. Conclusão: Se ocorrer uma exceção em um finalizador em um tipo e esse finalizador for executado antes que todos os testes tenham terminado, o Visual Studio fornecerá o erro que eu estava enfrentando; sem qualquer explicação adicional e em testes aleatórios.
driis

6
Não tenho finalizadores / destruidores em meu código ... ~ MyClass () e recebo o mesmo erro. Os testes de execução com Resharper são totalmente verdes
Peter Gfader

6
O problema com exceções não capturadas em finalizadores é um caso especial de exceções não capturadas em tarefas em segundo plano que podem ser iniciadas ou agendadas (talvez implicitamente) por algum teste e podem continuar executando mesmo se o teste foi concluído.
satorg

1
Assim como Peter, o corredor de teste do Resharper me dá tudo verde. O executor de teste do VS 2010 falha na classe com destruidor.
RyBolt

1
Eu acidentalmente codifiquei um loop recursivo infinito em meu método Dispose (), que também causou isso.
Robert,

88

Esta mensagem é causada por uma exceção em um thread diferente do thread de teste em execução . Todas as respostas até agora se resumem a esta explicação simples. Nesse caso, é um bug conhecido do Visual Studio não exibir nenhuma informação útil.

O executor de teste do Visual Studio engasga totalmente se um thread diferente do thread de teste em execução lançar uma exceção: ele é engolido e não há saída, nenhuma chance de interceptar e depurar e nada exceto uma bagunça queimada e latente que deveria ser sua unidade teste.


A mesma coisa aconteceu comigo também - meu teste estava gerando um segmento separado, que estava recebendo uma exceção. Capturar a exceção dentro do segmento pelo menos me permite imprimi-lo e saber o que está acontecendo. No entanto, tome cuidado para não colocar Assert.Fail () no bloco catch do thread - isso levanta uma exceção separada que o coloca de volta onde você começou.
Kyle Krull

4
a mesma coisa para mim, exceto um estouro de pilha, que são muito mais difíceis de rastrear em C # em comparação com java ...
John Gardner

Na verdade, percebi que isso aconteceu quando comecei a usar objetos Thread e chamar Abort () para interrompê-los.
espaciomore

1
Isso também acontece quando um async voidmétodo que é chamado durante o teste lança uma exceção
Mathias Becher

1
Observe que o trx pode conter as informações de erro; você pode vê-lo abrindo-o em um editor de texto ou no Visual Studio e clicando no hiperlink de erro de execução de teste na janela Resultados do teste .
Ohad Schneider

16

Eu estava tendo esse problema e acabou sendo um problema no meu código que o Test Framework não estava capturando corretamente. Uma pequena refatoração acidental me deixou com este código:

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

É claro que isso é uma recursão infinita e causou uma StackOverflowException (eu acho). O que isso causou foi o temido: "O processo do agente foi interrompido enquanto o teste estava em execução."

Uma rápida inspeção do código me mostrou o problema e meus testes agora estão funcionando bem. Espero que isso ajude - pode valer a pena inspecionar o código em busca de problemas, ou talvez extrair um pouco em um aplicativo de console e verificar se ele funciona corretamente lá.


3
Este não é o problema (eu sei porque são testes diferentes que falham a cada vez), mas obrigado por dedicar seu tempo para responder.
driis

6
+1, pois esta é uma das muitas respostas válidas para este problema. uma exceção SO em um método sstatic em uma de minhas classes causou esse problema.
Peter T. LaComb Jr.

6
+1, eu também vi isso. Depurar o teste (no VS 11) encontra o problema rapidamente.
Jeremy McGee

Concordo com Jeremy. Se você depurar os testes de unidade, ele deve parar onde a exceção é lançada. No entanto, se você apenas executar os testes de unidade, todos eles apresentarão luzes verdes. Muito bizarro.
Andrew Stephens de

8

Consegui encontrar a origem do meu problema procurando no arquivo de resultado do teste (/TestResults/*.trx). Ele forneceu todos os detalhes da exceção que ocorreu no thread de segundo plano e, assim que resolvi essa exceção, o "agente processou parou ... "o erro foi embora.

No meu caso, eu estava lançando acidentalmente a GUI em meu teste de unidade, o que eventualmente fez com que uma System.ComponentModel.InvalidAsynchronousStateException fosse lançada.

Portanto, meu arquivo .trx continha:

   <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>

Isso não forneceu nenhuma informação sobre qual teste causou o erro, mas me mostrou onde estava a exceção, o que foi muito útil.


5

Essa mensagem normalmente é gerada quando o processo de teste falha e pode acontecer quando há uma exceção não tratada em um encadeamento em segundo plano, ocorre um estouro de pilha ou uma chamada explícita para Process.GetCurrentProcess().Kill()ou Environment.Exit. Outra causa possível é uma violação de acesso em código não gerenciado.

Algo que ninguém mencionou é que pode haver informações adicionais no log de eventos. Normalmente, você não obterá muitas informações sobre o motivo da falha do teste nos resultados, no entanto, no caso de uma exceção não tratada em um thread de segundo plano, a estrutura de teste grava detalhes no log de eventos do aplicativo com a origem VSTTExecution. Se não houver informações gravadas no log de eventos, é provável que seja uma das outras causas listadas acima.


4

No meu caso, a solução foi resolvida verificando a janela de saída .

'QTAgent32.exe' (Gerenciado (v4.0.30319)): Carregado 'C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll', Símbolos carregados. E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, Unhandled Exception Caught, reporting through Watson: [Exception message]

No meu caso, tive um FileSystemWatcher que estava gerando um erro em um thread separado.


como você resolveu isso? Estou usando um código de amostra de M $ que envolve o FileSystemWatcher em um serviço e cria um fluxo de trabalho WF em torno disso. Estou recebendo muitos desses ...
ekkis

No meu caso, dois testes falharam. Quando fui para o painel Saída e escolhi Testes , ele mencionou "Um dos threads de fundo lançou uma exceção" ... na verdade, 9 NullReferenceExceptions estavam esperando por mim com rastreamentos de pilha. Obrigado, isso foi muito útil!
Qwertie

3

Eu encontrei o mesmo problema e resolvi durante a remoção

Environment.Exit(0);

Portanto, tenho certeza de que esse erro ocorre enquanto o teste ou método em teste está causando o encerramento do processo de execução.


2

Obrigado por postar a pergunta. Acabei de encontrar esse problema e descobri uma causa que você pode estar encontrando.

Uma exceção assíncrona pode ter ocorrido

Durante minha configuração de teste, crio um objeto que enfileira um thread de trabalho no pool de threads. Se eu executar a depuração rápido o suficiente, meu código será aprovado.

Se o thread de trabalho for iniciado e tiver um erro ANTES da conclusão da configuração do teste, recebo o resultado Abortado sem raciocínio.

Se o thread de trabalho for iniciado e tiver um erro APÓS o início do teste, obtenho o resultado de: Erro - O processo do agente foi interrompido durante a execução do teste.

Importante observar: este é um componente que utilizo em vários de meus testes. Se a estrutura de teste encontrar muitos desses erros, ele aborta o restante dos testes.

Espero que isto ajude


Obrigado pela resposta. Estou ciente de que as exceções assíncronas podem causar algo semelhante ao que estou vendo, mas tenho quase certeza de que não é o caso. O código é para um aplicativo da web e não fazemos nada de forma assíncrona. Além disso, parece que o teste que falha é aleatório.
driis

2

Eu adicionei blocos try / catch ao descrutor ~ ClassName () {} que foram definidos em qualquer classe envolvida em meus testes. Isso resolveu o problema para mim.

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

2

Para descobrir onde a exceção foi lançada, clique no hiperlink "Erro de execução de teste" ao lado do ícone de exclamação na janela Resultados do teste. Uma janela com o rastreamento de pilha é aberta.

Isso ajuda muito a rastrear o erro!


1

Eu tive o mesmo problema e foi causado por um finalizador para um recurso não gerenciado (um gravador de arquivo que não estava sendo descartado corretamente por algum motivo).

Depois de envolver o código finalizador em um try-catch que engole a exceção, o problema desapareceu. Eu não recomendo engolir exceções como essa, então obviamente seria sábio descobrir por que a exceção está ocorrendo em primeiro lugar.


1

Já vi isso acontecer em ocasiões ímpares, e o culpado quase sempre acaba sendo o threading.

Estranhamente, todos os testes funcionariam bem nas máquinas de desenvolvimento e, em seguida, falhariam aleatoriamente nos servidores de construção.

Em uma inspeção mais detalhada, descobriu-se que, embora os testes estivessem sendo listados como aprovados nas caixas de desenvolvimento, havia exceções sendo lançadas. As exceções estavam sendo lançadas em um thread separado que não foi considerado um erro.

Os detalhes da exceção estavam sendo registrados em relação ao rastreamento de teste, portanto, pudemos identificar quais códigos / testes precisavam ser modificados.

Espero que isso ajude alguém.


0

No meu caso, tive alguns testes de unidade para um serviço WCF. Este serviço WCF estava inicializando 2 temporizadores.
Esses temporizadores causaram efeitos colaterais.
-> Eu desabilito esses temporizadores por padrão e está tudo bem!

BTW: eu uso o WCFMock para falsificar o serviço WCF, então tenho testes de unidade "reais" em torno do meu serviço WCF


0

Este erro foi causado por um Finalizer para mim também.
O Finalizer estava realmente chamando algum código DB que não foi simulado. Levei um tempo para encontrá-lo, pois não era uma aula que eu escrevi e a referência a ele estava profundamente enterrada em algumas aulas.


0

Eu tive um problema semelhante em que um teste está falhando em TestInitialize e também está executando o código de um ddl de outro dos meus projetos. Recebo a mensagem de erro conforme descrito acima e, se tentar depurar o teste, ele será cancelado sem nenhum detalhe de exceção.

Suspeito que o problema pode ser que as dlls de meu outro projeto são de um projeto Visual Studio 2012 e estou executando meus testes em um projeto VS2010 e / ou possivelmente que as versões dll UnitTestFramwork dos 2 projetos são incompatíveis.


0

O problema também pode ser disparado por uma Exception ou Stackoverflow no Construtor de uma TestClass.


0

Como esse erro pode ter muitas causas diferentes, gostaria de adicionar outro para completar este tópico.

Se todos os seus testes estão sendo abortados conforme descrito pelo OP, a causa pode ser uma configuração de projeto errada. No meu caso, a estrutura de destino foi definida como .NET Framework 3.5. Configurá-lo para uma versão superior por meio da página de propriedades do projeto (guia Aplicativo ) resolveu o problema.


0

Consegui determinar o que estava causando meu problema procurando nas entradas de log do Windows Logs > Application no Windows Event Viewer . Procure entradas no momento em que o teste foi bombardeado. Eu tive uma entrada de erro semelhante a abaixo:

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

Na verdade, era uma exceção de referência nula em um método chamado de um finalizador de classe.


0

Para qualquer um que está passando por cima dessa velha questão e se perguntando o que está sendo jogado em seu (s) tópico (s), aqui vai uma dica. O uso de Task.Run (em oposição a, digamos, Thread.Start) relatará exceções de thread filho de maneira muito mais confiável. Resumindo, em vez disso:

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

Faça isso:

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

E seus logs de erro devem ser muito mais úteis.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.