vstest.executionengine.x86.exe ne ferme pas

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

Si je lance les tests (même si le test est aussi simple que de créer une nouvelle liste, sans affirmations), vstest.executionengine.x86.exe ne se ferme pas et rest en cours d’exécution dans le gestionnaire de tâches.

Cela pose un problème pour moi lorsqu’il s’agit d’écrire des tests plus complexes qui incluent la suppression de fichiers / nettoyage de bases de données sqllite.

Toute aide serait appréciée.

MODIFIER :

Étapes pour reproduire:

  • Créer un nouveau projet de test d’unité
  • Tests d’unité de débogage – vstest.executionengine.x86 s’ouvre et se ferme, les tests réussissent.
  • Run Unit Tests – vstest.executionengine.x86 s’ouvre et rest ouvert

C’est par conception.

Vstest.executionengine.exe est redémarré uniquement lorsque nous détectons une modification de la configuration entre deux séries de tests consécutives. Cela permet de s’assurer que nous ne prenons pas inutilement un redémarrage.

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 cours d’exécution». Vous pouvez décocher cette option pour désactiver le comportement par défaut.

J’ai contourné ce problème en utilisant ce qui suit comme événement de pré-construction 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 construire le projet de test. Le /FI "MEMUSAGE gt 1" arrête la commande (et donc la construction) de ne pas réussir si le moteur d’exécution ne fonctionne pas.

Pour ce que cela vaut, je suis tombé sur 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 n’a pas été fermée avant la fin du test. Je ne suis pas sûr de savoir pourquoi quitter le test ne m’a pas permis de résoudre ce problème, mais lorsque j’ai corrigé mon code pour éliminer correctement toutes les ressources ouvertes, tout a fonctionné comme prévu. Je n’ai pas eu à append de hacks pour tuer le vstest.executionengine.exe , ni à désactiver Test -> Test Settings -> Keep Test Execution Engine Running

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

Un test que IDisposable objects qui implémentaient IDisposable , alors l’parsing de code m’a dit que ma classe de test devrait l’être également. Il a fallu du temps pour le réaliser, mais quand cela se this.Dispose(); était appelé sur l’implémentation de cette interface quand je l’ai mis sur ma classe de test, il lançait en réalité une exception StackOverflow. Donc, je viens de taper l’interface et laisser CA continuer à pleurnicher.

Je n’ai pas eu besoin de basculer «Garder le moteur d’exécution des tests en cours».

J’ai eu ce problème lors de l’exécution du test en utilisant le testeur Resharper qui ne semble pas respecter le Test-->Test Settings-->Keep Test Execution Engine Running . Dans mon cas, la construction échouait avec l’erreur suivante:

warning MSB3026: Impossible de copier “… \ SQLite.Interop.dll” dans “bin \ Debug \ x86 \ SQLite.Interop.dll”. Commencer à réessayer 10 dans 1000ms. 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é-construction au projet de test, tel que suggéré par @HappyCat, a fonctionné pour moi. J’avais également besoin de l’envelopper 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 tâches.

 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" )