Er is een fout opgetreden bij het uitvoeren van eenheidstests. Als ik de eenheidstests debuggen, wordt vstest.executionengine.x86.exe uitgevoerd en wordt vervolgens gesloten wanneer de tests slagen.
Als ik gewoon de tests uitvoer (zelfs als de test zo simpel is als het maken van een nieuwe lijst, zonder beweringen), sluit vstest.executionengine.x86.exe niet en blijft actief in taakbeheer.
Dit veroorzaakt een probleem voor mij als het gaat om het schrijven van meer gecompliceerde tests, waaronder het verwijderen van bestanden / het opschonen van sqllite-databases.
Alle hulp wordt op prijs gesteld.
BEWERK:
Stappen om te reproduceren:
- Nieuw eenheidstestproject maken
- Debug Unit Tests – vstest.executionengine.x86 opent en sluit, test geslaagd.
- Eenheidstests uitvoeren – vstest.executionengine.x86 opent en blijft open
Antwoord 1, autoriteit 100%
Dit is zo ontworpen.
De vstest.executionengine.exe wordt alleen opnieuw gestart wanneer we een wijziging in de configuratie detecteren tussen twee opeenvolgende testruns. Dit helpt ervoor te zorgen dat we niet onnodig een fout maken bij het opnieuw opstarten van processen.
Productupdate
Met VS2013 hebben we een nieuw menu-item onder Test -> Testinstellingen genaamd “Keep Test Execution Engine Running”. U kunt dit uitschakelen om u af te melden voor het standaardgedrag.
Antwoord 2, autoriteit 72%
Ik heb dit omzeild door het volgende te gebruiken als een pre-build evenement voor de betrokken testprojecten:
voor 64-bit:
taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"
of voor 32-bit:
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"
Hiermee wordt de uitvoeringsengine stilzwijgend uitgeschakeld voordat het testproject wordt gebouwd. De /FI "MEMUSAGE gt 1"zorgt ervoor dat de opdracht (en dus de build) niet mislukt als de uitvoeringsengine niet actief is.
Antwoord 3, autoriteit 9%
Voor wat het waard is, ik kwam dezelfde situatie tegen en het bleek dat ik een test had die niet alle bronnen goed opruimde. In mijn specifieke geval was er een achtergrondthread met een open netwerkverbinding die niet werd gesloten voordat de test werd afgesloten. Ik weet niet zeker waarom het afsluiten van de test dit niet voor mij heeft afgesloten, maar toen ik mijn code repareerde om alle bronnen die ik had geopend op de juiste manier te verwijderen, werkte alles zoals verwacht. Ik hoefde geen hacks toe te voegen om de vstest.executionengine.exete doden, noch hoefde ik me af te melden voor Test -> Test Settings -> Keep Test Execution Engine Running
Antwoord 4, autoriteit 4%
Ik had dit probleem bij het uitvoeren van een test met Resharper’s testrunner, die de instelling Test-->Test Settings-->Keep Test Execution Engine Runningniet lijkt te respecteren. In mijn geval zorgde het ervoor dat de build mislukte met de volgende fout:
waarschuwing MSB3026: kan “…\SQLite.Interop.dll” niet kopiëren naar “bin\Debug\x86\SQLite.Interop.dll”. Begin opnieuw met 10 in 1000 ms. Het proces heeft geen toegang tot het bestand ‘bin\Debug\x86\SQLite.Interop.dll’ omdat het door een ander proces wordt gebruikt.
Het toevoegen van een pre-build evenement aan het testproject zoals @HappyCat suggereerde werkte voor mij. Ik moest het ook in een if-statement plaatsen om te voorkomen dat het op de buildserver wordt uitgevoerd en andere taken verstoort.
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"
)
Antwoord 5, autoriteit 2%
Ik weet dat dit oud is, maar ik dacht ik gooi er iets in dat ik net heb ontdekt.
Een test die ik aan het uitvoeren was, bevatte enkele objecten die IDisposableimplementeerden, dus de code-analyse vertelde me dat mijn testklasse dat ook zou moeten doen. Het duurde een tijdje om het te beseffen, maar toen this.Dispose();werd opgeroepen voor de implementatie van die interface toen ik het in mijn testklasse plaatste, veroorzaakte het eigenlijk een StackOverflow-uitzondering. Dus ik rukte gewoon aan de interface en liet CA blijven zeuren.
Ik hoefde ‘Keep Test Execution Engine Running’ niet in te schakelen.
Antwoord 6
De gemakkelijkste manier is om naar Windows Taakbeheer te gaan. Let op het vstest.executionengine.exe-proces dat op de achtergrond wordt uitgevoerd. Dood dat proces en het zou nu goed moeten werken.