Запуск mstest * без * с использованием ThreadPool
Я пишу некоторый управляемый код, чтобы обернуть нативные вызовы для RTX-продукта IntervalZero. RTX в основном позволяет в реальном времени кодировать под Windows, настраивая прокси ядра. Здесь важно то, что RTX генерирует прокси, когда DllMain вызывается с DLL_THREAD_ATTACH (и срывает его с DLL_THREAD_DETACH). Если этот прокси не был сгенерирован, и вы делаете вызов в библиотеку, вы получаете немедленный BSOD.
Ну, я на 99,9% уверен, что когда mstest.exe запускает свои модульные тесты, он ставит их в очередь, используя класс ThreadPool (это единственное, что объясняет это поведение). Прискорбно то, что поток уже был создан еще до загрузки библиотеки RTX, поэтому DllMain никогда не вызывается, а подсистема RTX не знает о ее существовании, и поэтому, когда модульный тест пытается вызвать библиотеку, все отменяется.,
Мне действительно нужно иметь возможность запускать юнит-тесты на этом материале, чтобы я мог получить разумное, автоматизированное тестовое покрытие. Есть ли способ сказать mstest для создания нового потока во время выполнения для каждого теста? Я знаю, что обычно это будет медленнее, но все равно будет намного быстрее, чем возвращаться после синего экрана.
2 ответа
Ну, так как мой коэффициент принятия низкий из-за подобных вопросов, я дам ответ (хотя и не тот, который мне нравится). Я не думаю, что заставить mstest вести себя по-другому (то есть использовать один поток на тест) возможно. Я попробовал почти все мыслимые. Обходным путем для этого было написать простое приложение для запуска тестов, которое использовало бы отражение для загрузки и запуска тестов. Делая это, я сохранил синтаксис mstest (хотя и с гораздо меньшими возможностями).
В долгосрочной перспективе должно произойти то, что API-интерфейсам RTX нужен массаж, чтобы быть более дружелюбным. Я работаю с OEM, чтобы попытаться получить это в следующем выпуске.
Пытались использовать другую среду, отличную от MSTest, например, nUnit, чтобы увидеть, воспроизводит ли это проблему?