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


101

Dans Visual Studio 2010, j'ai un certain nombre de tests unitaires. Lorsque j'exécute plusieurs tests à la fois à l'aide de listes de tests, je reçois parfois l'erreur suivante pour un ou plusieurs des tests:

Le processus d'agent a été arrêté pendant l'exécution du test.

Ce n'est jamais le même test qui échoue, et si j'essaye de le relancer, il réussit.

J'ai trouvé ce rapport de bogue sur Connect , qui semble être le même problème, mais il n'offre pas de solution.

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

Éditer

Je rencontre toujours ce bogue, de même que beaucoup de mes collègues sur la même configuration logicielle / matérielle. J'ai évalué les réponses jusqu'à présent, mais elles ne résolvent pas le problème. Je commence une prime pour une solution à ce problème.


J'obtiens la même chose. Je creuse dedans mais pas de solution pour l'instant
Mark

des nouvelles à ce sujet? Même problème ici ...
Peter Gfader

@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.
driis

J'ai eu le même comportement avec une exception non interceptée. L'exception était visible pour moi lorsque j'exécutais Visual Studio sur le serveur de génération et que j'obtenais une Assert-Window. En raison de la fenêtre d'assertion, le test n'a pas pu continuer.

Réponses:


41

Je viens de rencontrer le problème similaire: certains tests échouent et ils sont différents dans différentes exécutions de test. Je ne sais pas exactement pourquoi cela arrive, 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 finaliseur, le problème revient.

Pour le moment, je ne sais pas comment surmonter cela.


16
MERCI - cette réponse m'a conduit à la solution. Je n'ai qu'un finaliseur sur quelques types, et bien sûr, les supprimer a également supprimé le problème. Après une enquête plus approfondie, j'ai découvert un bogue subtil dans un finaliseur, qui ne s'est produit que lorsqu'une exception a été 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 finaliseur sur un type et que ce finaliseur s'exécute avant que tous les tests ne soient terminés, Visual Studio donnera l'erreur à laquelle j'étais confronté; sans autre explication, et sur des tests aléatoires.
driis

6
Je n'ai pas de finaliseurs / destructeurs dans mon code ... ~ MyClass () et j'obtiens la même erreur. Les tests en cours avec Resharper sont tous verts
Peter Gfader

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

1
Comme Peter, le testeur Resharper me donne tout vert. Le testeur VS 2010 échoue sur la classe avec le destructeur.
RyBolt

1
J'avais accidentellement codé une boucle récursive infinie dans ma méthode Dispose (), ce qui a également causé cela.
Robert

88

Ce message est provoqué par une exception sur un thread différent du thread de test en cours d'exécution . Toutes les réponses jusqu'à présent se résument à cette simple explication. C'est un bogue connu dans Visual Studio de ne pas afficher d'informations sensibles dans ce cas.

Le testeur de Visual Studio s'étouffe totalement si un thread autre que le thread de test en cours d'exécution lève une exception: il est avalé et il n'y a pas de sortie, aucune chance d'intercepter et de déboguer et rien d'autre qu'un désordre brûlé qui était censé être votre unité tester.


La même chose s'est produite pour moi aussi - mon test engendrait un thread séparé, qui recevait une exception. Attraper l'exception à l'intérieur du fil me permet au moins de l'imprimer et de savoir ce qui se passe. Cependant, veillez à ne pas mettre Assert.Fail () dans le bloc catch du thread - cela déclenche une exception distincte qui vous ramène là où vous avez commencé.
Kyle Krull

4
même chose pour moi, sauf un débordement de pile, qui est tellement plus difficile à repérer en C # qu'en java ...
John Gardner

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

1
Cela se produit également lorsqu'une async voidméthode appelée pendant le test lève une exception
Mathias Becher

1
Notez que le trx peut contenir les informations d'erreur, vous pouvez le voir soit en l'ouvrant dans un éditeur de texte, soit dans Visual Studio et en cliquant sur le lien hypertexte Erreur d'exécution du test dans la fenêtre Résultats du test .
Ohad Schneider

16

J'avais ce problème, et il s'est avéré être un problème dans mon code que le cadre de test ne captait pas correctement. Un petit refactoring accidentel m'avait laissé ce code:

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

Il s'agit bien sûr d'une récursivité infinie et a provoqué une StackOverflowException (je suppose). Cela a provoqué le redouté: "Le processus de l'agent a été arrêté pendant que le test était en cours d'exécution."

Une inspection rapide du code m'a montré le problème, et mes tests fonctionnent maintenant correctement. J'espère que 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 qu'il fonctionne correctement là-bas.


3
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.
driis

6
+1 car c'est l'une des nombreuses réponses valables à ce problème. une exception SO dans une méthode sstatic sur l'une de mes classes a causé ce problème.
Peter T.LaComb Jr.23

6
+1, j'ai vu ça aussi. Le débogage du test (dans VS 11) trouve le problème assez rapidement.
Jeremy McGee

D'accord avec Jeremy. Si vous déboguez les tests unitaires, il doit s'arrêter là où l'exception est levée. Cependant, si vous ne faites que lancer les tests unitaires, ils s'allumeront tous en vert. Très bizarre.
Andrew Stephens

8

J'ai pu trouver la source de mon problème en regardant dans le fichier de résultat du test (/TestResults/*.trx) Il a fourni tous les détails de l'exception qui s'est produite dans le thread d'arrière-plan, et une fois que j'ai résolu cette exception, l'agent a traité arrêté ... "l'erreur a disparu.

Dans mon cas, je lancais involontairement l'interface graphique dans mon test unitaire, ce qui a finalement provoqué la levée 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 fourni aucune information sur le test qui a causé l'erreur, mais cela m'a montré où se trouvait l'exception, ce qui était très utile.


5

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

Ce que personne n'a mentionné, c'est qu'il peut y avoir des informations supplémentaires dans le journal des événements. Habituellement, vous n'obtiendrez pas beaucoup d'informations sur la raison pour laquelle le test a planté dans les résultats, mais en cas d'exception non gérée sur un thread d'arrière-plan, le framework de test écrit les détails dans le journal des événements d'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 répertoriées ci-dessus.


4

Dans mon cas, la solution a été résolue en vérifiant la fenêtre de sortie .

'QTAgent32.exe' (géré (v4.0.30319)): chargé 'C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll', symboles chargés. E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, Exception non gérée interceptée, rapport via Watson: [Message d'exception]

Dans mon cas, j'avais un FileSystemWatcher qui lançait une erreur sur un thread séparé.


comment l'avez-vous résolu? J'utilise un exemple de code de M $ qui enveloppe le FileSystemWatcher dans un service et crée un flux de travail WF autour de cela. Je reçois beaucoup de ces ...
ekkis

Dans mon cas, deux tests ont échoué. Lorsque je suis allé dans le volet Sortie et que j'ai choisi Tests , il a mentionné "Un des threads d'arrière-plan a jeté une exception" ... en fait, 9 NullReferenceExceptions m'attendaient avec des traces de pile. Merci, ceci était vraiment utile!
Qwertie le

3

J'ai rencontré le même problème et je l'ai résolu en supprimant

Environment.Exit(0);

Je suis donc presque sûr que cette erreur se produit pendant que votre test ou votre méthode en cours de test entraîne la fin du processus d'exécution.


2

Merci d'avoir posé la question. Je viens de rencontrer ce problème et j'ai découvert une cause que vous pourriez rencontrer.

Une exception asynchrone peut s'être produite

Au cours de ma configuration de test, je crée un objet qui met en file d'attente un thread de travail dans le pool de threads. Si j'exécute le débogage assez rapidement, mon code passe.

Si le thread de travail démarre et a une erreur AVANT la fin de la configuration du test, j'obtiens un résultat Aborted sans raisonnement.

Si le thread de travail démarre et présente une erreur APRÈS le début du test, j'obtiens le résultat: Erreur - Le processus d'agent a été arrêté pendant l'exécution du test.

Important à noter: c'est un composant que j'utilise tout au long de plusieurs de mes tests. Si le framework de test rencontre trop de ces erreurs, il abandonne le reste des tests.

J'espère que cela t'aides


Merci pour la réponse. Je suis conscient que les exceptions asynchrones peuvent provoquer quelque chose de similaire à ce que je vois, mais je suis presque certain que ce n'est pas le cas. Le code est destiné à une application Web et nous ne faisons rien de manière asynchrone. En outre, il semble que le test qui échoue soit aléatoire.
driis

2

J'ai ajouté des blocs try / catch au descructor ~ ClassName () {} qui ont été définis dans n'importe quelle classe impliquée dans mes tests. Cela a résolu le problème pour moi.

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

2

Pour savoir où l'exception a été lancée, cliquez sur le lien hypertexte "Erreur d'exécution du test" à côté de l'icône d'exclamation dans la fenêtre Résultats du test. Une fenêtre avec la trace de la pile s'ouvre.

Cela aide beaucoup à localiser l'erreur!


1

J'ai eu le même problème et il a été causé par un finaliseur pour une ressource non gérée (un écrivain de fichier qui n'était pas éliminé correctement pour une raison quelconque).

Après avoir enveloppé le code du finaliseur dans un try-catch qui avale l'exception, le problème a disparu. Je ne recommande pas d'avaler des exceptions comme celle-là, il serait donc évidemment sage de savoir pourquoi l'exception se produit en premier lieu.


1

J'ai eu cela à l'occasion étrange, et le coupable s'avère presque toujours être en train de filer.

Curieusement, tous les tests fonctionneraient correctement sur les machines de développement, puis échoueraient de manière aléatoire sur les serveurs de construction.

En y regardant de plus près, il s'est avéré que bien que les tests aient été répertoriés comme réussis sur les boîtes de développement, il y avait des exceptions. Les exceptions étaient lancées sur un thread séparé qui n'a pas été détecté comme une erreur.

Les détails de l'exception étaient enregistrés par rapport à la trace de test, nous avons donc pu identifier le code / les tests devant être modifiés.

J'espère que cela aide quelqu'un.


0

Dans mon cas, j'ai eu des tests unitaires pour un service WCF. Ce service WCF démarrait 2 minuteries.
Ces minuteries ont causé des effets secondaires.
-> Je désactive ces minuteries par défaut et tout va bien!

BTW: J'utilise WCFMock pour simuler le service WCF, donc j'ai de «vrais» tests unitaires autour de mon service WCF


0

Cette erreur a également été causée par un Finalizer pour moi.
Le Finalizer appelait effectivement du code DB qui n'a pas été simulé. Il m'a fallu un certain temps pour le trouver car ce n'était pas un cours que j'avais écrit et la référence à cela était enfouie dans plusieurs classes.


0

J'ai rencontré un problème similaire où un test échoue dans TestInitialize et exécute également du code à partir d'un ddl d'un autre de mes projets. J'obtiens le message d'erreur comme décrit ci-dessus et si j'essaie de déboguer le test, le test est simplement abandonné sans aucun détail d'exception.

Je soupçonne que le problème peut être que les dll de mon autre projet proviennent d'un projet Visual Studio 2012 et que j'exécute mes tests dans un projet VS2010, et / ou peut-être que les versions des dll UnitTestFramwork des 2 projets ne correspondent pas.


0

Le problème peut également être déclenché par une exception ou un Stackoverflow dans le constructeur d'un TestClass.


0

Comme cette erreur peut avoir de nombreuses causes différentes, j'aimerais en ajouter une autre pour l'exhaustivité de ce fil.

Si tous vos tests échouent comme décrit par l'OP, la cause peut être une mauvaise configuration de projet. Dans mon cas, le framework cible a été défini sur .NET Framework 3.5. Le définir sur une version supérieure via la page des propriétés du projet (onglet Application ) a résolu le problème.


0

J'ai pu déterminer la cause de mon problème en regardant dans les journaux Windows > les entrées du journal des applications dans l' observateur d'événements Windows . Recherchez les entrées au moment où le test a été bombardé. J'ai eu une entrée d' erreur similaire à ci-dessous:

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

Il s'agissait en effet d'une exception de référence nulle dans une méthode appelée depuis un finaliseur de classe.


0

Pour quiconque se pose sur cette vieille question et se demande ce qui est jeté de son (ses) fil (s), voici une astuce. L'utilisation de Task.Run (par opposition à, par exemple, Thread.Start) signalera les exceptions de thread enfant de manière beaucoup plus fiable. Bref, au lieu de ça:

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

Faites ceci:

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

Et vos journaux d'erreurs devraient être beaucoup plus utiles.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.