NUnit игнорирует DomainUsage в файле runsettings

Я не верю, что ты сможешь это сделать.

1. Нет распознанного элемента DomainUsage под NUnit в файле runsettings. DomainUsage - это внутренне используемое свойство, которое будет учитываться, если установлено. Но вы не можете так настроить. Ваш элемент DomainUsage просто игнорируется.

2. Если адаптер получил вашу DisableAppDomain настройку, он установит DomainUsage на None. Однако я не верю, что он действительно его получает.

Пункт 2 требует пояснений. Обратите внимание, что я не работал над адаптером несколько лет и иду по памяти, но вот он ...

Был добавлен параметр DisableAppDomain, позволяющий Visual Studio принудительно запускать NUnit без использования AppDomain. Предполагается, что обозреватель тестов настроит все так, чтобы было возможно работать таким образом, то есть убедившись, что все уже доступно в текущем домене.

Я считаю, что во избежание неправильного использования этой функции Test Explorer всегда переопределяет любые пользовательские настройки. Опять же, это из памяти о работе, которая была проделана несколько лет назад, но похоже, что результаты, которые вы видите, подтверждают это.

Обоснованием этого прошлого решения было то, что Test Explorer полностью отвечает за настройку Process и AppDomain, используемых для запуска тестов. У пользователя нет возможности повлиять на это, как и у NUnit. Конечно, при использовании средства запуска консоли это не так - управление находится в руках пользователя.

Еще нужно выяснить, почему вы чувствуете необходимость работать без создания AppDomain теста. Но это, наверное, другой вопрос. :-)

Я попрошу некоторых других людей, у которых, возможно, память лучше, чем у меня, тоже взглянуть на это.

ОБНОВИТЬ:

@Terje, который сейчас обслуживает адаптер, ответил и подтвердил, что нет никакого способа установить DomainUsage в файле runsettings или каким-либо другим известным нам способом при работе с тестовым адаптером. Документы были исправлены, чтобы избежать неявного предположения, что это возможно.

Мы считаем, но не подтвердили экспериментально, что TestExplorer создает свой собственный домен приложения всякий раз, когда он использует этот параметр для подавления его создания тестовым адаптером.

Этот ответ является продолжением ответа от @charlie выше, просто нужно немного места здесь. Я проверил создаваемые домены в зависимости от того, установлен ли DisableAppDomain или нет. Когда отключенный домен приложения не установлен, домен приложения создается NUnit с базой приложения и понятным именем, как показано ниже:

NUnitCheckDomain - это тестовая dll.

Когда отключен домен приложения установлен, NUnit больше не устанавливает свой собственный домен, и вы затем видите, что он работает под доменом приложения testhost, который является процессом, выполняющим все тесты:

Так что, похоже, это работает так, как должно и может. Вам нужно, чтобы он работал под каким-либо другим доменом приложения, кроме одного из этих?

Кстати: если я запускаю тестовую сборку NUnitCheckDomain с помощью консоли NUnit3, то она а) работает при прямом запуске б) вылетает при использовании с параметрами, которые вы указали выше (domain = None и --inprocess), не имея возможности загрузить NUnit.Framework . @charlie - По какой-либо причине это не должно работать так же, используя NUnit3-Console?