102 votes

Erreur VS 2010 Test Runner "Le processus de l'agent a été arrêté pendant l'exécution du test".

Dans Visual Studio 2010, je dispose d'un certain nombre de tests unitaires. Lorsque j'exécute plusieurs tests en même temps à l'aide de listes de tests, je reçois parfois l'erreur suivante pour un ou plusieurs des tests :

Le processus de l'agent a été arrêté alors que le test était en cours.

Ce n'est jamais le même test qui échoue, et si j'essaie d'exécuter à nouveau le test, il réussit.

J'ai trouvé ceci rapport de bogue sur Connect qui semble être le même problème, mais qui ne propose pas de solution.

Quelqu'un d'autre a-t-il constaté ce comportement ? Comment puis-je l'éviter ?

Modifier

Je suis toujours confronté à ce problème, tout comme bon nombre de mes collègues qui utilisent la même configuration logicielle et matérielle. J'ai évalué les réponses jusqu'à présent, mais elles ne résolvent pas le problème. Je lance un appel à dons pour trouver une solution à ce problème.

0 votes

J'ai la même chose. Je creuse la question mais je n'ai pas encore trouvé de solution.

0 votes

Des nouvelles à ce sujet ? Même problème ici...

0 votes

@Peter, voir mon commentaire ci-dessous réponse acceptée. C'était ma solution, mais je ne sais pas si votre problème est similaire.

89voto

mafu Points 8920

Ce message est causé par un exception sur un thread différent du thread de test en cours d'exécution . Toutes les réponses obtenues jusqu'à présent se résument à cette simple explication. Il s'agit d'un bogue connu de Visual Studio qui n'affiche aucune information sensée dans ce cas.

L'exécuteur de tests de Visual Studio se bloque totalement si un thread autre que le thread de test en cours d'exécution lève une exception : Elle est avalée et il n'y a pas de sortie, pas de possibilité d'interception et de débogage et rien d'autre qu'un désordre brûlé et fumant qui était censé être votre test unitaire.

0 votes

La même chose s'est produite pour moi aussi - mon test générait un thread séparé, qui obtenait une exception. Le fait d'attraper l'exception dans le thread me permet au moins de l'imprimer et de savoir ce qui se passe. Cependant, faites attention à ne pas mettre Assert.Fail() dans le bloc catch du thread - cela lève une exception séparée qui vous ramène au point de départ.

4 votes

Même chose pour moi, à l'exception d'un débordement de pile, qui sont tellement plus difficiles à repérer en C# par rapport à Java...

0 votes

En effet, j'ai remarqué que cela se produisait lorsque j'ai commencé à utiliser des objets Thread et à appeler Abort() pour les arrêter.

42voto

satorg Points 610

Je viens de rencontrer le même problème : certains tests échouent et ils sont différents dans les différentes séries de tests. Je ne sais pas exactement la raison pour laquelle cela se produit, mais cela a commencé à se produire lorsque j'ai ajouté un finaliseur à l'une de mes classes. Lorsque je désactive le finaliseur - le problème disparaît. Lorsque j'active le finalisateur, le problème revient.

Pour l'instant, je ne sais pas comment surmonter cela.

16 votes

MERCI - cette réponse m'a conduit à la solution. Je n'ai un finalisateur que sur quelques types, et bien sûr, en les supprimant, j'ai également résolu le problème. Après une enquête plus approfondie, j'ai découvert un bogue subtil dans un finaliseur, qui ne se produit que lorsqu'une exception est levée dans le constructeur et que le finaliseur tente de finaliser un objet qui n'est pas entièrement construit. Conclusion : Si une exception se produit dans un finalizer sur un type, et que ce finalizer s'exécute avant que tous les tests soient terminés, Visual Studio donnera l'erreur à laquelle j'étais confronté ; sans aucune autre explication, et sur des tests aléatoires.

6 votes

Je n'ai pas de finaliseurs/destructeurs dans mon code ... ~MyClass() et j'obtiens la même erreur. Les tests exécutés avec Resharper sont tous verts

6 votes

Le problème des exceptions non capturées dans les finaliseurs est un cas particulier d'exceptions non capturées dans les tâches d'arrière-plan qui peuvent être lancées ou planifiées (peut-être implicitement) par un test et qui peuvent continuer à s'exécuter même si le test est terminé.

17voto

Simon Steele Points 8344

J'ai eu ce problème, et il s'est avéré être un problème dans mon code que le Test Framework ne capturait pas correctement. Un petit remaniement accidentel m'avait laissé avec ce code :

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

Il s'agit bien sûr d'une récursion infinie, qui a provoqué une StackOverflowException (je suppose). Ce que cela a causé était le redoutable : "Le processus de l'agent a été arrêté pendant l'exécution du test."

Une rapide inspection du code m'a montré le problème, et mes tests se déroulent maintenant sans problème. J'espère que cela vous aidera - cela peut valoir la peine d'inspecter le code à la recherche de problèmes, ou peut-être d'en extraire un peu dans une application console et de vérifier que cela fonctionne correctement.

3 votes

Ce n'est pas le problème (je le sais car ce sont des tests différents qui échouent à chaque fois), mais merci d'avoir pris le temps de répondre.

7 votes

+1 car c'est l'une des nombreuses réponses valables pour ce problème. une exception SO dans une méthode sstatic sur l'une de mes classes a causé ce problème.

6 votes

+1, j'ai vu ça aussi. En déboguant le test (dans VS 11), on trouve le problème assez rapidement.

8voto

Denise Skidmore Points 1014

J'ai pu trouver la source de mon problème en consultant le fichier de résultats du test (/TestResults/*.trx). Il fournit tous les détails de l'exception qui s'est produite dans le fil d'arrière-plan, et une fois que j'ai résolu cette exception, l'erreur "agent processed stopped..." a disparu.

Dans mon cas, j'ai lancé involontairement l'interface graphique dans mon test unitaire, ce qui a entraîné l'apparition d'une exception System.ComponentModel.InvalidAsynchronousStateException.

Donc mon fichier .trx contenait :

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

Cela n'a pas fourni d'informations sur le test qui a causé l'erreur, mais cela m'a montré où se trouvait l'exception, ce qui était très utile.

5voto

mike z Points 14365

Ce message est généralement généré lorsque le processus de test se bloque et peut se produire lorsqu'une exception n'est pas gérée sur un thread d'arrière-plan, qu'un dépassement de pile se produit ou qu'un appel explicite à la fonction Process.GetCurrentProcess().Kill() ou Environment.Exit . Une autre cause possible est une violation d'accès dans un code non géré.

Personne n'a mentionné le fait que le journal des événements peut contenir des informations supplémentaires. Habituellement, vous n'obtiendrez pas beaucoup d'informations sur la raison pour laquelle le test a échoué dans les résultats, mais dans le cas d'une exception non gérée sur un thread d'arrière-plan, le cadre de test écrit les détails dans le journal des événements de l'application avec la source VSTTExecution. Si aucune information n'est écrite dans le journal des événements, il s'agit probablement de l'une des autres causes énumérées ci-dessus.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X