Vstest.executionengine.x86.exe не закрывается

У меня возникла ошибка при выполнении модульных тестов. Если я отлаживаю модульные тесты vstest.executionengine.x86.exe, то закрывается, когда проходят тесты.

Если я просто запускаю тесты (даже если тест такой же простой, как просто создание нового списка без утверждений), vstest.executionengine.x86.exe не закрывается и остается в диспетчере задач.

Это вызывает у меня проблему, когда дело доходит до написания более сложных тестов, которые включают удаление файлов/очистку SQL-баз данных.

Любая помощь будет оценена.

ИЗМЕНИТЬ:

Шаги для воспроизведения:

Создать новый проект Unit Test
Тесты отладки блока - vstest.executionengine.x86 открывается и закрывается, проходит тест.
Выполнять тесты блока - vstest.executionengine.x86 открывается и остается открытым.

Ответ 1

Это по дизайну.

vstest.executionengine.exe перезапускается только тогда, когда мы обнаруживаем изменение конфигурации между двумя последовательными тестовыми запусками. Это помогает гарантировать, что мы не принимаем перфоманс при перезагрузке процесса без необходимости.

Обновление продукта С VS2013 у нас есть новый пункт меню в разделе Test → Test Settings, который называется "Keep Engine Execution Engine Running". Вы можете снять этот флажок, чтобы отказаться от поведения по умолчанию.

Ответ 2

Я работал над этим, используя следующее в качестве события предварительной сборки в затронутых тестовых проектах:

для 64-битного:

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

или для 32-битного:

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

Это тихо убивает механизм выполнения перед созданием тестового проекта. /FI "MEMUSAGE gt 1" останавливает выполнение команды (и, следовательно, сборку), если механизм выполнения не запущен.

Ответ 3

В чем его ценность, я столкнулся с этой ситуацией, и оказалось, что у меня был тест, который неправильно очистил все его ресурсы. В моем конкретном случае был фоновый поток с открытым сетевым подключением, который не закрывался до выхода теста. Не знаю, почему выход из теста не закрыл это для меня, но когда я исправил свой код, чтобы правильно распоряжаться всеми открытыми ресурсами, все работало так, как ожидалось. Мне не нужно было добавлять хаки, чтобы убить vstest.executionengine.exe, и я не должен был отказаться от Test -> Test Settings -> Keep Test Execution Engine Running

Ответ 4

У меня возникла эта проблема при запуске теста с использованием тестового бегуна Resharper, который, похоже, не соответствует настройке Test-->Test Settings-->Keep Test Execution Engine Running. В моем случае это вызвало сбои сборки со следующей ошибкой:

warning MSB3026: Не удалось скопировать "...\SQLite.Interop.dll" в "bin\Debug\x86\SQLite.Interop.dll". Начало повторения 10 в 1000 мс. Процесс не может получить доступ к файлу 'bin\Debug\x86\SQLite.Interop.dll', потому что он используется другим процессом.

Добавление события предварительной сборки в тестовый проект, как предлагал @HappyCat для меня. Мне также нужно было обернуть его в оператор if, чтобы он не работал на сервере сборки и не вмешивался в другие задания.

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

Ответ 5

Я знаю, что это старо, но я думал, что брошу что-то, что только что обнаружил.

В тесте, который я запускал, были некоторые объекты в нем, которые реализовали IDisposable, поэтому анализ кода сказал мне так, чтобы мой тестовый класс. Понадобилось некоторое время, чтобы понять это, но когда this.Dispose(); получал вызов реализации этого интерфейса, когда я помещал его в свой тестовый класс, он фактически бросал исключение StackOverflow. Поэтому я просто дернул интерфейс и позволил CA продолжать скулить.

Мне не нужно было переключать "Keep Engine Execution Engine Running".

Ответ 6

Самый простой подход - перейти к диспетчеру задач Windows. Обратите внимание на процесс vstest.executionengine.exe, работающий в фоновом режиме. Убейте этот процесс, и теперь он должен работать нормально.