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.

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.

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.

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.

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.

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.

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

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.

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

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());
    }
}

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!

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.

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.

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

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.

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.

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

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.

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.

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.