Erreur VS 2010 Test Runner "Le processus de l'agent a été arrêté pendant l'exécution du test."
Dans Visual Studio 2010, j'ai plusieurs tests unitaires. Lorsque j'exécute plusieurs tests à la fois à l'aide de listes de tests, il arrive que l'erreur suivante s'affiche 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'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 at-il vu ce comportement? Comment puis-je l'éviter?
Modifier
Je rencontre toujours ce bogue et beaucoup de mes collègues partagent 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.
Je viens de rencontrer un problème similaire: certains tests échouent et ils sont différents dans différentes exécutions. Je ne sais pas exactement pourquoi cela se produit, mais cela a commencé 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.
À l'heure actuelle, je ne sais pas comment surmonter cela.
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 jusqu'à présent se résument à cette explication simple. C’est un bogue connu dans Visual Studio de ne pas afficher d’informations sensibles dans ce cas.
Le lanceur de tests de Visual Studio s'étouffe totalement si un thread autre que le thread de test en cours d'exécution génère une exception: il est avalé et il n'y a pas de sortie, pas de possibilité d'interception et de débogage, ni rien sauf un fouillis qui couvait supposé était votre unité tester.
J'avais ce problème, et il s'est avéré que c'était un problème dans mon code que le framework de test n'interceptait pas correctement. Un peu de refactoring accidentel m'avait laissé avec ce code:
public void GetThingy()
{
this.GetThingy();
}
Ceci est bien sûr une récursion infinie, et a provoqué une StackOverflowException (je suppose). Cela a provoqué l'effroi: "Le processus de l'agent a été arrêté pendant l'exécution du test."
Une inspection rapide du code m'a montré le problème et mes tests fonctionnent maintenant correctement. J'espère que cela vous aidera - cela vaudra peut-être la peine d'inspecter le code à la recherche de problèmes, ou peut-être d'extraire un peu dans une application console et de vérifier qu'il fonctionne correctement là-bas.
J'ai été en mesure de trouver la source de mon problème en consultant le fichier de résultat du test (/TestResults/*.trx). Il fournissait tous les détails de l'exception survenue dans le thread d'arrière-plan. arrêté ... "erreur est parti.
Dans mon cas, je lançais 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 ne donnait aucune information sur le test qui avait provoqué l'erreur, mais il m'indiquait où était l'exception, ce qui était très utile.
Ce message est généralement généré lorsque le processus de test tombe en panne et peut se produire lorsqu'une exception non gérée sur un thread en 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 le code non géré.
Quelque chose que personne n'a mentionné, c'est qu'il peut y avoir des informations supplémentaires dans le journal des événements. Généralement, vous n'obtiendrez pas beaucoup d'informations sur la raison pour laquelle le test s'est écrasé dans les résultats. Toutefois, en cas d'exception non gérée sur un thread en arrière-plan, l'infrastructure de test écrit les détails dans le journal des événements de l'application avec le code source VSTTExecution. Si aucune information n’est écrite dans le journal des événements, il s’agit probablement d’une des causes énumérées ci-dessus.
J'ai rencontré le même problème et l'ai résolu en supprimant
Environment.Exit(0);
Je suis donc à peu près sûr que cette erreur se produit pendant que votre test ou méthode à tester provoque l'arrêt du processus en cours.
Merci d'avoir posté la question. J'ai juste rencontré ce problème et trouvé une cause que vous pourriez rencontrer.
Une exception asynchrone peut avoir eu lieu
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 je lance le débogage assez rapidement, mon code passe.
Si le thread de travail démarre et a une erreur AVANT que la configuration du test soit terminée, j'obtiens un résultat Aborted sans raisonnement.
Si le thread de travail démarre et a une erreur APRÈS le début du test, le résultat est le suivant: Erreur: le processus de l'agent a été arrêté pendant l'exécution du test.
Important à noter: c’est un composant que j’utilise au cours 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
J'ai ajouté des blocs try/catch au descripteur ~ ClassName () {} défini 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());
}
}
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, non géré Exception Caught, rapportant à travers Watson: [message d'exception]
Dans mon cas, un système FileSystemWatcher renvoyait une erreur sur un thread séparé.
Pour savoir où l'exception a été levée, cliquez sur le lien hypertexte "Erreur d'exécution de test" en regard de l'icône d'exclamation dans la fenêtre Résultats du test. Une fenêtre avec la trace de la pile est ouverte.
Cela aide beaucoup à traquer l'erreur!
J'ai eu le même problème et il a été causé par un finaliseur pour une ressource non gérée (un graveur 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 de ce type, il serait donc sage de chercher à savoir pourquoi cette exception se produit au départ.
Cela m'est arrivé à l'occasion, et le coupable s'avère presque toujours être enfilé.
Curieusement, tous les tests fonctionneraient correctement sur les machines de développement, puis échoueraient de manière aléatoire sur les serveurs de compilation.
En y regardant de plus près, il s’est avéré que bien que les tests aient été répertoriés comme ayant été passés avec succès sur les boîtes de dev, des exceptions ont été lancées. Les exceptions ont été lancées sur un fil séparé qui n'a pas été pris comme une erreur.
Les détails de l'exception ont été consignés dans la trace de test. Nous avons donc pu identifier le code/les tests à modifier.
J'espère que ça aide quelqu'un.
J'ai pu déterminer la cause de mon problème en consultant les entrées Journaux Windows > Application log dans le Observateur d'événements Windows . Recherchez les entrées au moment du test. J'ai eu un Erreur entrée semblable à 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 bien d'une exception de référence nulle au sein d'une méthode appelée à partir d'un finaliseur de classe.
Comme cette erreur peut avoir de nombreuses causes différentes, j'aimerais en ajouter une autre pour que ce fil soit complet.
Si tous vos tests échouent comme décrit par l'OP, la cause peut être une configuration de projet incorrecte. Dans mon cas, le framework cible était défini sur .NET Framework 3.5. Le réglage sur une version supérieure via la page de propriétés du projet (onglet Application ) a résolu le problème.
Le problème peut également être déclenché par une exception ou un flux de pile dans le constructeur d'une classe TestClass.
J'ai rencontré un problème similaire dans lequel un test échoue dans TestInitialize et qui exécute également du code à partir d'un ddl provenant d'un autre de mes projets. Je reçois le message d'erreur décrit ci-dessus et si j'essaie de déboguer le test, celui-ci est simplement abandonné sans détails sur les exceptions.
Je soupçonne que le problème peut provenir du fait que les dll de mon autre projet proviennent d'un projet Visual Studio 2012 et que je suis en train d'exécuter mes tests dans un projet VS2010 et/ou que les versions des dll UnitTestFramwork des deux projets ne sont pas compatibles.
Cette erreur a également été causée par un finaliseur.
Le Finalizer était en train d’appeler 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'ai écrit et la référence à ce sujet était complexe.
Dans mon cas, j'ai eu quelques tests unitaires pour un service WCF. Ce service WCF était en train de démarrer 2 minuteries.
Ces minuteries ont provoqué des effets secondaires.
-> Je désactive ces minuteries par défaut et tout va bien!
BTW: J'utilise WCFMock pour simuler le service WCF, j'ai donc de "vrais" tests unitaires autour de mon service WCF