Pourquoi Run All provoque-t-il un blocage des tests de l'unité VS2012 alors que l'exécution un par un ne le fait pas?
Nous venons de "mettre à niveau" Visual Studio 2008 vers Visual Studio 2012. Nous avons mis à jour nos tests unitaires. Ils sont maintenant réussis lorsqu'ils sont exécutés individuellement, mais lorsque j'essaie d'exécuter tout, j'ai le message d'erreur suivant:
The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either
at the machine level or for process vstest.executionengine.appcontainer.x86.exe. Go to more details: [http://go.Microsoft.com/fwlink/?linkid=232477][1]
Alors je suis allé au link et ai suivi les instructions pour ajouter la clé de registre pour permettre des sauvegardes sur crash locales. Le message d'erreur est alors devenu:
The active Test Run was aborted because the execution process exited unexpectedly. Check the execution process logs for more information.
If the logs are not enabled, then enable the logs and try again.
Apparemment, il a remarqué les modifications que j'ai apportées dans le registre pour activer le crash. Cependant, lorsque j'ai consulté% LOCALAPPDATA%\CrashDumps, aucun fichier n'a été créé.
Si je fais un test à la fois (ou même quelques tests à la fois), je peux tous les faire passer. Le problème est seulement avec Run All.
Quelqu'un at-il rencontré des problèmes similaires? Si oui, comment les avez-vous résolus?
La même question a essentiellement été posée sur MSDN , mais la réponse a ressemblé à "Cliquez sur le lien du vidage sur incident". Cette réponse ne m'aide pas car je ne vois aucun lien vers le vidage sur incident et je ne parviens pas à générer le vidage sur incident.
Cette question sur StackOverflow est également similaire et a abouti à un bogue consigné sur Microsoft Connect (qui semble différer pour une raison quelconque), mais mon problème pourrait être différent car mon code n'a rien faire avec des "tâches asynchrones" (je ne pense pas).
EDIT: Le problème a disparu, apparemment tout seul, mais il s’agissait probablement d’une exception qui n’était pas prise en compte par le code de test unitaire, comme le suggèrent certaines des réponses ci-dessous. Cependant, je ne comprends toujours pas pourquoi le problème est apparu uniquement avec Run All, et non lorsque vous exécutez des groupes de tests plus petits ou Debug All.
J'ai eu le même problème, les tests ont échoué pour apparemment aucune raison. Plus tard, j'ai découvert qu'une méthode buggy causait une StackOverflowException. Lorsque j'ai corrigé mon bogue, le bogue VS a disparu.
Peut-être que cela fonctionne la plupart du temps parce que vous n'exécutez pas le code défectueux.
La meilleure solution de contournement que j'ai à ce jour consiste à tout déboguer. Cela se fait via TEST -> Debug -> Tous les tests. C'est évidemment plus lent mais ça ne plante pas.
Pour toute autre personne susceptible d'en avoir besoin à l'avenir: Mon programme d'exécution de test se bloquait lorsqu'une commande spécifique à la console (Environment.Exit (-1);) a été exécutée via le test unitaire. Même exécuter en mode débogage planterait simplement - je ne pouvais pas obtenir un message d'erreur utile.
Donc, mon scénario est différent du scénario de la question principale en ce sens que a) le débogage ne fonctionnait pas du tout b) exécuter tous les vs individuellement ne faisait aucune différence. C’est parce que mon scénario d’erreur se produisait toujours, mais pas les débordements de pile de la question initiale.
La ligne du bas: test runner est mauvais et va planter s'il trouve quelque chose qu'il n'aime pas. Vous devez manuellement isoler et déterminer ce qu'est le Bad Thing ™.
Cela peut arriver avec certaines erreurs, telles qu'un stackoverflow. Vraisemblablement, cela plante le testeur et ne peut donc pas continuer lorsqu'il réussit un test à l'origine du problème.
La solution consiste donc à exécuter tous les tests en mode débogage (à partir du menu Test -> Déboguer) et Visual Studio affichera des erreurs comme celles-ci.
Pour quelqu'un d'autre à la recherche de ceci: j'avais un code qui appelait System.Environment.Exit (123) et je ne le savais pas. Vérifiez donc tout code qui termine le processus.
Je viens d'avoir le même problème. Il s’est avéré que c’était mon code - il y avait une boucle infinie d’appels de service WCF. Dans votre cas, cela pourrait être autre chose. Ma proposition consiste donc à mémoriser (journaux dans le système de contrôle de version?) Ou à déterminer (en excluant différents tests de l'exécution, par exemple avec la méthode de bissection) quel emplacement dans le code entraîne ce comportement. Et wuala! C'est la cause du problème et en même temps un bug dans le code.
UPDATE Comme pour les questions de votre EDIT. Il peut arriver que l'exécution de groupes de tests plus petits ne reproduise pas le problème. Dans ce cas, étant donné que ces groupes incluent tous les tests, on peut supposer que certains tests interfèrent. Peut-être des données ou des champs statiques dans une classe de tests? En ce qui concerne l'exécution de tests en mode débogage - je ne suis pas surpris. Le lanceur de tests Visual Studio se comporte différemment en mode "Exécuter" et en mode "Débogage".
J'ai eu un problème similaire, sauf que ce n'était pas une exception stackoverflow. Cela est dû au fait que mon projet testé utilise Entity Framework et le projet NUnit n'ayant pas de références inclus dans les modules EntityFramework et EntityFramework.SqlServer. L'ajout de références aux modules Entity Framework l'a corrigé.
Juste eu le même problème. La fermeture et la réouverture de Visual Studio l’a corrigé.