web-dev-qa-db-fra.com

vstest.executionengine.x86.exe ne se ferme pas

J'ai rencontré une erreur lors de l'exécution des tests unitaires. Si je débogue les tests unitaires vstest.executionengine.x86.exe s'exécute, puis se ferme lorsque les tests réussissent.

Si je viens d'exécuter les tests (même si le test est aussi simple que de créer une nouvelle liste, sans assertions), vstest.executionengine.x86.exe ne se ferme pas et continue de fonctionner dans le gestionnaire de tâches.

Cela me pose un problème lorsqu'il s'agit d'écrire des tests plus compliqués, notamment la suppression de fichiers/le nettoyage de bases de données sqllite.

Toute aide serait appréciée.

ÉDITER :

Étapes à reproduire:

  • Créer un nouveau projet de test unitaire
  • Déboguer les tests unitaires - vstest.executionengine.x86 s'ouvre et se ferme, les tests réussissent.
  • Exécuter les tests unitaires - vstest.executionengine.x86 s'ouvre et reste ouvert
unit-testingtestingvisual-studio-2012
48
Jamez

C'est par conception.

Le vstest.executionengine.exe est redémarré uniquement lorsque nous détectons un changement dans la configuration entre deux exécutions de test consécutives. Cela permet de s'assurer que nous ne prenons pas un coup sûr au redémarrage du processus inutilement.

Mise à jour du produit Avec VS2013, nous avons un nouvel élément de menu sous Test -> Paramètres de test appelé "Garder le moteur d'exécution du test en marche". Vous pouvez décocher cette option pour désactiver le comportement par défaut.

56
allen

J'ai contourné ce problème en utilisant ce qui suit comme événement de pré-génération sur les projets de test concernés:

pour 64 bits:

taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"

ou pour 32 bits:

taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"

Cela tue silencieusement le moteur d'exécution avant de générer le projet de test. Le /FI "MEMUSAGE gt 1" arrête la commande (et donc la build) d'échouer si le moteur d'exécution n'est pas en cours d'exécution.

40
HappyCat

Pour ce que ça vaut, j'ai rencontré cette même situation et il s'est avéré que j'avais un test qui ne nettoyait pas correctement toutes ses ressources. Dans mon cas spécifique, il y avait un thread d'arrière-plan avec une connexion réseau ouverte qui ne s'est pas fermée avant la fin du test. Je ne sais pas pourquoi quitter le test n'a pas fermé cela pour moi, mais quand j'ai corrigé mon code pour disposer correctement de toutes les ressources que j'ai ouvertes, tout a fonctionné comme prévu. Je n'ai pas eu à ajouter de hacks pour tuer le vstest.executionengine.exe, et je n'ai pas non plus dû me désabonner de Test -> Test Settings -> Keep Test Execution Engine Running

5
Lucas

J'ai eu ce problème lors de l'exécution de test à l'aide du lanceur de test de Resharper qui ne semble pas respecter le Test-->Test Settings-->Keep Test Execution Engine Running réglage. Dans mon cas, cela provoquait l'échec de la génération avec l'erreur suivante:

avertissement MSB3026: impossible de copier "...\SQLite.Interop.dll" vers "bin\Debug\x86\SQLite.Interop.dll". Commencez à réessayer 10 dans 1000 ms. Le processus ne peut pas accéder au fichier "bin\Debug\x86\SQLite.Interop.dll" car il est utilisé par un autre processus.

L'ajout d'un événement de pré-génération au projet de test comme l'a suggéré @HappyCat a fonctionné pour moi. J'ai également dû l'encapsuler dans une instruction if pour l'empêcher de s'exécuter sur le serveur de génération et d'interférer avec d'autres travaux.

if $(ConfigurationName) == Debug (
    echo "attempting to kill vstest to prevent access denied on sqlite.interop.dll"
    taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"
)
2
Seth Reno

Je sais que c'est vieux mais je pensais que je mettrais quelque chose que je viens de découvrir.

Un test que j'exécutais contenait des objets qui implémentaient IDisposable, donc l'analyse de code me l'a dit, ma classe de test devrait en faire autant. Il a fallu un certain temps pour le réaliser, mais lorsque this.Dispose(); était appelé sur l'implémentation de cette interface lorsque je l'ai mise dans ma classe de test, il lançait en fait une exception StackOverflow. J'ai donc simplement tiré sur l'interface et laissé CA continuer à pleurnicher.

Je n'avais pas besoin de basculer "Garder le moteur d'exécution du test en marche".

1
ArcaneVibe

L'approche la plus simple consiste à accéder au gestionnaire de tâches Windows. Recherchez le processus vstest.executionengine.exe exécuté en arrière-plan. Tuez ce processus et cela devrait fonctionner correctement maintenant.

0
Pradeep