MSTest & AppDomains

Question

В некоторых моих проектах я заметил, что во время выполнения модульных тестов под VSTS2008 потребление памяти VSTestHost растет. Поскольку в моем решении очень много тестов, это в конечном итоге приводит к исключению OutOfMemroyException. Это выглядит очень странно для меня, так как я был уверен, что MSTest создает новый домен приложений для каждого модульного теста. Иначе как бы сбросить статические поля? Но если AppDomain создается для каждого теста, память не должна просачиваться. Но это так.

Таким образом, вопрос: должен ли VS создавать AppDomain для каждого тестового класса или нет? Если да, то как я могу проверить, что он это делает. Я попытался отследить через ProcessExpolorer и оснастку Performance. Во время выполнения теста значение "Всего выгружено домена приложения" всегда равно 0.

Answer 1

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

Если вы видите утечки, это, вероятно, но либо в вашем тестовом коде, либо в коде вашего продукта. Убедитесь, что вы не вставляете вещи в словари и не оставляете их там.

Answer 2

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

Visual Studio 2008 использует отдельный исполняемый файл vstesthost.exe для запуска модульных тестов. VS связывается с vstesthost.exe (как он это делает, я не знаю), чтобы сказать ему, какие тесты для запуска. vstesthost.exe возвращает результаты выполнения в VS, который отображает эти результаты.

Если вы получаете OutOfMemoryExceptions при запуске ваших модульных тестов, я бы сказал, что это сильный индикатор того, что тестируемый код на самом деле не очищает вещи. Вы уверены, что не сохраняете дескрипторы неуправляемых объектов / памяти? Я бы порекомендовал запускать ваши модульные тесты с помощью Performance Analysis (вы можете сделать это, найдя модульный тест в «Test View», щелкнув по нему правой кнопкой мыши и выбрав «Create Performance Session»). Это может пролить некоторый свет, по крайней мере, на распределение объектов.

Answer 3

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

Вот доказательство: синглтон

public class Singleton
{
    public static Singleton Instance = new Singleton();

    private Guid _token;
    private Singleton()
    {
        _token = Guid.NewGuid();
    }

    public Guid Token
    {
        get { return _token; }
    }
}

и два теста:

[TestClass]
public class UnitTest2
{
    [TestMethod]
    public void TestMethod1()
    {
        Console.WriteLine(Singleton.Instance.Token);
    }
}
[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void TestMethod1()
    {
        Console.WriteLine(Singleton.Instance.Token);
    }
}

Во время выполнения обоих тестов вывести одинаковые направляющие.

Answer 4

Единственный способ избавиться от синглтона - это избавиться от домена приложения. Синглтон - это статическая привязка к самому себе, поэтому это в основном круговая ссылка. Истинные синглтоны не удаляются, пока домен приложения не исчезнет.

Answer 5

Видна та же проблема с большими тестовыми прогонами. Моя теория заключается в следующем. Исчерпание памяти в этом случае происходит из-за того, что файлы результатов теста MSTest имеют формат XML. Поэтому необходимо сохранить все результаты журнала в памяти до конца тестового прогона перед сериализацией на диск. Ура для XML: -)

Я опубликовал эту проблему как проблема с подключением некоторое время назад, и это должно было быть исправлено в MSTest 10 (собирается 64-разрядная версия), но я пока не смог проверить это из-за другие проблемы у нас переходят на VS2010 и .NET 4.0.

Answer 6

Это не решается в MSTest 2010. У меня много подобных проблем. Почему сборка мусора не работает в модульном тесте?

Насколько я понимаю, среда UT позаботилась об удалении всех выполненных тестов, но, похоже, это не относится к некоторым одноэлементным шаблонам, которые мы имеем в коде.