Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 15.04.15 13:35
Оценка: 113 (12) +1
Всем доброго дня!

Мы написали фреймворк для юнит тестирования памяти .Net приложений. Хотелось бы обсудить насколько это может быть интересно и вообще получить фидбэк по функциональности.

Фреймворк распространяется в виде нугет пакета (https://www.nuget.org/packages/JetBrains.DotMemoryUnit/) и совершенно бесплатен. Все что необходимо иметь это юниттест раннер от джетбрейнса, то есть иметь установленный ReSharper 9.1 или dotCover 3.1.
Отдельный "запускатель" таких тестов нами запланирован на будущее.

Что умеет фреймворк:

— выбирать объекты по типам, интерфейсам, неймспейсам, поколениям
— сравнивать срезы памяти — выбирать новые объекты, умершие, выжившие
— добывать информацию о мемори траффике, в том числе поддерживаются ассерты на траффик с помощью атрибутов.
— у любой выборки объектов можно посмотреть количество памяти и объектов
— фреймворк интегрируется с NUnit и MSTest (вообще говоря с любым юнит тест фреймворком)

Краткое описание использования: http://blog.jetbrains.com/dotnet/2015/03/04/unit-testing-and-memory-profiling-can-they-be-combined/ (англ.)
Страничка со ссылками на хэлп и инструкциями по инсталляции: https://www.jetbrains.com/dotmemory/unit/ (англ.)

P.S.: Почему здесь, а не в jetbrains форуме? Потому что он бесплатный — это раз. И потому что хочется узнать насколько юнит тестирование памяти интересно — это два, а здесь аудитория, наверное, побольше.
Re[3]: Юнит тестирование "памяти"
От: Sinix  
Дата: 16.04.15 11:09
Оценка: 59 (2) +1
Здравствуйте, fedor.reznik, Вы писали:

FR>Unmanaged не может( Но имею встречный вопрос: по каким критериям хотелось бы кверить куски unmanged память из юнит тестов написанных на .Net? А то она ведь совсем "разная" и просто мерить ее объем, имхо, большого смысла не имеет.

Если речь про утечки, порождённые managed-кодом, то я бы смотрел на наследников UnsafeHandle и на IntPtr.
Это и с текущим API в принципе можно сделать.


Да, такое пожелание: при дизайне API начинайте со сценариев использования

Серьёзно, примеры безумно многословны (отдельное фу-фу-фу за примеры картинками без ссылки на текст).
Большая часть прекрасно сводится к хелперам для типовых сценариев аля
MemAssert.WillNotLeak<SomeObj>(Threshold.FromKilobytes(12));

Не, конечно можно (и нужно) добавить подходящие хелперы самостоятельно, но как минимум заготовки (чтобы подсказать направление движения) должны присутствовать из коробки.


И, если уж речь зашла про работу с памятью, есть ли поддержка тестов для декларирования побочных эффектов?
Например, есть код на partially immutable-типах, было бы очень здорово находить ошибки вида "объект изменяется, хотя не должен".

В ту же степь — проверки для pure-функций (речь об вот этих вот),
или проверки вида "состояние объекта x эквивалентно состоянию на момент вот этого снапшота" — полезно для отладки автоматов, визиторов, undo-redo и тд и тп.

В принципе часть решается ручной расстановкой отладочных ассертов, но кто будет следить, что все ассерты расставлены верно?
Re[6]: Юнит тестирование "памяти"
От: drol  
Дата: 27.04.15 21:45
Оценка: 36 (1) +1
Здравствуйте, Spinifex, Вы писали:

S>Т.е. если вы используете Automation API (это все продукты: White, MS CodedUI, Ranorex и т.п.) у вас приложение под тестами будет гарантировано "протекать".


Да даже не обязательно прямо использовать и не только под тестами. Для кучи глюков достаточно просто активации UI Automation чем-нибудь снаружи. А кто только не активирует... Например, драйвера\софт планшетов Wacom... Не говоря уж об accessibility-фичах...

В своё время кучу багов на тему зарепортил. Вот, например: 549867 UI Automation throws unexpected exceptions in XBAP application

*Кривость Microsoft Connect не знает границ... Чтобы увидеть старый баг надо идти на archive.org
Re[7]: Юнит тестирование "памяти"
От: KRT Украина  
Дата: 13.05.15 10:21
Оценка: 36 (1) +1
Здравствуйте, fedor.reznik, Вы писали:

И ещё немного офтопика Есть планы по поддержке WinPhone? Хотя бы 10 (у них вроде бы теперь общий код с "большой" windows). И может что-то известно про dotTrace, в смысле поддержки винфона 10.
Re[6]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 23.04.15 11:02
Оценка: 32 (1) +1
Здравствуйте, Sinix, Вы писали:

S>Есть ещё вариант 2: я тормоз, код — обычный сценарный тест и тут вообще речь не про тестирование с использованием DotMemoryUnit

Эм... Ну как бы да, в данном случае вариант два
Там был ответ про то, что сценарные тесты тоже можно писать в виде "обычных" тест классов/методов. Как следствие в них использовать DotMemoryUnit.

S>Если со вторым вариантом угадал — как в DotMemoryUnit будет выглядеть типовой тест для сферического кода в вакууме?

S>В моём представлении код должен выглядеть примерно так (псевдокод):
S>
S>var memoryContract = Memory
S>  .WillNotLeak(threshold: 1kb)
S>  .NoLohInstances()
S>  .MaxAllocates(10mb)
S>  .WarnOnMidlifeCrisis()

S>using (new AssertionScope(memoryContract))
S>{
S>  SomeUseCase();
S>}
S>


S>Если у вас будет другой способ — делитесь, интересно


В целом, и он и правда будет выглядеть примерно так, с поправкой на то, что, как Вы помните, у нас сейчас нет таких "супер хелперов".
И вместо using (new AssertionScope(memoryContract)) мы делаем dotMemory.Check(memory => <asserts>).

Но Ваша идея с хелперами мне нравится)
Re[5]: Юнит тестирование "памяти"
От: Sinix  
Дата: 16.04.15 13:24
Оценка: 10 (1) +1
Здравствуйте, fedor.reznik, Вы писали:

FR>Так в общем-то мы с них и начинали. Это так сказать продукт не в последнюю очередь выросший из производственной необходимости)

Тогда дважды ок
Из практики — все хорошие проекты так и начинались.


FR>В первой версии хотелось предоставить максимально гибкий инструмент, а потом посмотреть на "хотелки".

Не, само общее API обязательно должно быть. Проблема в том, что API никак не подсказывает пользователю, как ему решать свои проблемы.
Вместо этого на пользователя вываливается стартовый пример с готовым карго-решением (aka делай вот так и всё будет зашибись).

Причём один и тот же по сути пример в блоге записан тремя разными подходами. Иногда "Assert.That", иногда "Assert.AreEqual". Такая мешанина ещё больше запутывает.

В общем надо или писать понятное API, начиная с сценариев со стороны пользователя, или строить какую-то ментальную модель, и уже по ней обучать пользователя.
Чтобы тот понял, что главная фишка в api от dotMemory, и что смотреть надо на него, а не на 5 способов записать один и тот же Assert


FR>Кроме того, очевидно ли Вам, что строчка MemAssert.WillNotLeak<SomeObj>(Threshold.FromKilobytes(12)) — приведет к взятию снапшота (не быстрая операция) и этот ассерт валиден только в данной точке? А еще нам совсем не хотелось писать свой язык ассертов, чтобы не ломать экспириенс.

Хороший вопрос

Скорее всего тут нужен метод с делегатом, как в "dotMemory.Check(()=>...)", или оборачивание всей проверяемой области в using. Второе, наверно, будет лучше.

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

Ну, или начинать API с конкретных сценариев: сначала написать "код мечты", а затем сообразить, как подогнать под него более общее API.


FR>Правильно ли я понял, что Ваш ассерт сводится к такому:

Ага.

FR>А если хочется ассертить сразу несколько вещей (типов)? Лямбда это позволяет. Хотя можно оттопырить таких методов у чекпойнта. Подумаем.

Угу. Наглядный пример, как легко упустить важные моменты в погоне за красивым кодом
В принципе решается оборачиванием в using аля
using (WillNotLeak(someCondition))
{
  // some code
}


или той же лямбдой. Но это надо на реальном коде проверять смначала. Сорри, что повторяюсь но тут лучше перестраховаться, чем потом объяснять, что имел в виду.




FR>А вот это интересно! Осталось только договориться что такое "измененный объект" и "состояние объекта"?

FR>Например, в dotMemory мы умеем показывать значение филдов, соответственно, здесь это тоже реализуемо.

Навскидку тут всего два варианта:

1. Сравнение графа объектов. Примитивы понятно как сравнивать, типы с IEquatable — тоже, остальное — обходом графа, циклы пропускать
2. Через code instrumentation отслеживать изменения полей. Намного сложнее и куда больше шансов ложных срабатываний

Дорогое конечно удовольствие, но другого способа тестировать самые адские баги типа таких
Автор: nikov
Дата: 02.07.14
никто пока не придумал.
Re: Юнит тестирование "памяти" - CI is available
От: fedor.reznik  
Дата: 12.08.15 09:19
Оценка: 9 (2)
Здравствуйте, fedor.reznik, Вы писали:

FR>Всем доброго дня!


FR>Мы написали фреймворк для юнит тестирования памяти .Net приложений. Хотелось бы обсудить насколько это может быть интересно и вообще получить фидбэк по функциональности.


Всем, кто ждал стандалоне раннера и возможности интеграции с CI — welcome Resharper EAP 9.2 — dotMemory Unit Standalone Launcher.
Это зипничек, перед разархиврованием надо сделать Unblock из свойств файла (по крайней мере на Win 8) — иначе винда его считает "подозрительным". Далее "dotMemoryUnit.exe /?" и вперед
Вообще говоря, документация готова, но выложить мы ее можем только после релиза и не спрашивайте меня почему.

BTW, если кто знает как заставить винду считать архив безопасным — буду очень благодарен
Re[11]: Юнит тестирование "памяти"
От: Tom Россия http://www.RSDN.ru
Дата: 20.04.15 16:26
Оценка: +2
FR>А аттачиться нельзя, потому что замедляет или политики безопасности? А дамп при этом можно?
Атачиться нельзя по многим причинам.
Во первых у меня на продакшине тысяч 10 активных пользователей к серверам обращается и что будет при присоединении профайлера и тем более при сборе снэпшотов никому неизвестно.
Лучшее что может произойти — некоторые клиенты получат таймаутом по башке.
Во вторых кроме как OnDemand бывают OnPremise инсталяции в разных там банках а там сесуриту итп.
А дамп (procdump), при условии клонирования процесса (-r) операция давольно безопасная.

FR>Но при этом у Вас очевидно есть возможность туда пойти и снять дамп, что несколько нарушает фразу "никто в приличном обществе к продакшину неподпустит"

Не нарушает. Ибо дамп в состоянии сделать OPS товарищи, тогда как для работы с профайлером нужна много большая квалификация.

FR>В теории есть еще третий вариант, мы сейчас обкатываем так называемый self-profiling API, который позволяет оттопырить из приложения условно кнопку — дай мне перформанс снапшот, дай мне мемори снапшот,

FR>на выходе получается файл, который умеет открывать dotMemory или dotTrace, соответственно.
FR>А это уже не сильно отличается от "зайти и снять дамп".
FR>В данный момент такая функциональность доступна по запросу.
Мммм для нас бесполезно. Ибо по сути будет означать подключение профайлера.

FR>Вы не поймите меня не правильно, дампы мы и сами хотим сделать.

FR>Просто хочется понять можно ли помочь большинству тех, кто хочет дампы, уже существующими средствами.
Можно.Сделайте дампы
Народная мудрось
всем все никому ничего(с).
Re[2]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 22.04.15 09:53
Оценка: 54 (1)
Здравствуйте, Spinifex, Вы писали:

S>Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.

S>Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.

Вообще говоря, профилировать имеет смысл только Release версии. Хотя ваш пример несколько искусственный и в реальности таких засад будет меньше, но тем не менее.

S>На мой взгляд было бы удобным иметь возможность получать размер не только объекта, но и все его ссылок.

Их есть у нас!

var memoryCheckPoint1 = dotMemory.Check(
              memory =>
                   {
                        Assert.AreEqual(2, memory
                    .GetObjects(where => where.Type.Is<Some>())
                    .GetExclusivelyRetainedObjects() // получает выборку объектов удерживаемым данной выборкой
                    .ObjectsCount, "Неверное количество объектов");
                    }
                );


S>Когда планируется интеграция с CI?

Собственно она уже в разработке. Так что, видимо, в ближайших релизах. Скажем так, до конца года с вероятностью 99% Может и пораньше.

UPD: GC.Collect() можно не вызывать. Снятие снапшота (чек-пойнта), гарантирует сборку мусора.
Отредактировано 22.04.2015 9:58 fedor.reznik . Предыдущая версия .
Re[6]: Юнит тестирование "памяти"
От: Ed.ward Россия  
Дата: 23.04.15 11:28
Оценка: 54 (1)
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, fedor.reznik, Вы писали:


FR>>Давайте я покажу как выглядит сценарный тест dotMemory:


S>Такой вопрос: что в тесте — инфраструктурный код от DotMemoryUnit, а что — собственно тест?

S>Если весь код кроме Assert.That() — это инфраструктура, то выглядит страшновато.

S>Есть ещё вариант 2: я тормоз, код — обычный сценарный тест и тут вообще речь не про тестирование с использованием DotMemoryUnit


S>Если со вторым вариантом угадал — как в DotMemoryUnit будет выглядеть типовой тест для сферического кода в вакууме?

S>В моём представлении код должен выглядеть примерно так (псевдокод):
S>
S>var memoryContract = Memory
S>  .WillNotLeak(threshold: 1kb)
S>  .NoLohInstances()
S>  .MaxAllocates(10mb)
S>  .WarnOnMidlifeCrisis()

S>using (new AssertionScope(memoryContract))
S>{
S>  SomeUseCase();
S>}
S>


S>Т.е. отдельно прописываем гарантии для кода (не течём, не замусориваем LOH, дельта по памяти — не больше 10 МБ, код не становится причиной Mid-life crisis), отдельно — запускаем сценарий.


S>Если у вас будет другой способ — делитесь, интересно


Примерно так это можно сделать.

Action memoryContract = () => dotMemory.Check(memory =>
{
  Assert.LessThan(1024, memory.GetObjects(where => where.Type.Is<Foo>()).SizeInBytes );
  Assert.AreEqual(0, memory.GetObjects(where => where.Generation.Is(Generation.LOH)).SizeInBytes);
  Assert.AreEqual(0, memory.GetObjects(where => where.ObjectsAreInMidCrisis()).ObjectsCount);
});

SomeUseCase();
memoryContract();


Ed.ward
Отредактировано 23.04.2015 11:31 Ed.ward . Предыдущая версия .
Re[4]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 16.04.15 11:39
Оценка: 36 (1)
Здравствуйте, Sinix, Вы писали:

S>Да, такое пожелание: при дизайне API начинайте со сценариев использования


Так в общем-то мы с них и начинали. Это так сказать продукт не в последнюю очередь выросший из производственной необходимости)

S>Серьёзно, примеры безумно многословны (отдельное фу-фу-фу за примеры картинками без ссылки на текст).

За фу-фу-фу, посыпаю голову пеплом, но ничего сделать не могу такие вот движки у нас на сайте(

S>Большая часть прекрасно сводится к хелперам для типовых сценариев аля

S>
S>MemAssert.WillNotLeak<SomeObj>(Threshold.FromKilobytes(12));
S>

S>Не, конечно можно (и нужно) добавить подходящие хелперы самостоятельно, но как минимум заготовки (чтобы подсказать направление движения) должны присутствовать из коробки.

В первой версии хотелось предоставить максимально гибкий инструмент, а потом посмотреть на "хотелки". Кроме того, очевидно ли Вам, что строчка MemAssert.WillNotLeak<SomeObj>(Threshold.FromKilobytes(12)) — приведет к взятию снапшота (не быстрая операция) и этот ассерт валиден только в данной точке? А еще нам совсем не хотелось писать свой язык ассертов, чтобы не ломать экспириенс.

Правильно ли я понял, что Ваш ассерт сводится к такому:

dotMemory.Check(memory => {
    var os = memory.GetObjects(where => where.Type.Is<SomeObj>());
    Assert.That(os.SizeInBytes, Is.LessThan(12*1024));
});


А если хочется ассертить сразу несколько вещей (типов)? Лямбда это позволяет. Хотя можно оттопырить таких методов у чекпойнта. Подумаем.

S>И, если уж речь зашла про работу с памятью, есть ли поддержка тестов для декларирования побочных эффектов?

S>Например, есть код на partially immutable-типах, было бы очень здорово находить ошибки вида "объект изменяется, хотя не должен".

S>В ту же степь — проверки для pure-функций (речь об вот этих вот),

S> или проверки вида "состояние объекта x эквивалентно состоянию на момент вот этого снапшота" — полезно для отладки автоматов, визиторов, undo-redo и тд и тп.

А вот это интересно! Осталось только договориться что такое "измененный объект" и "состояние объекта"?
Например, в dotMemory мы умеем показывать значение филдов, соответственно, здесь это тоже реализуемо.
Re[14]: Юнит тестирование "памяти"
От: WW898 Германия  
Дата: 22.04.15 09:46
Оценка: 36 (1)
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, fedor.reznik, Вы писали:


FR>>Если будет время воспроизведите, пожалуйста, сразу с логами:


S>В логах ничего толком нет, воспроизвёл кодом:

S>
S>    static void Main()
S>    {
S>        var l = new List<IntPtr>();
S>        var size = 64 * 1024 * 1024;
S>        for (int i = 0; i < 1024*1024; i++)
S>        {
S>            try
S>            {
S>                l.Add(Marshal.AllocCoTaskMem(size));
S>            }
S>            catch (Exception)
S>            {
S>                size /= 2;
S>            }
S>            Console.WriteLine("{0:N2} kb", Process.GetCurrentProcess().VirtualMemorySize64 / 1024.0);

S>            Thread.Sleep(1000);
S>        }
S>        GC.KeepAlive(l);
S>        Console.WriteLine("Done.");
S>        Console.ReadKey();
S>    }
S>


S>Сборка debug, x86, .net 3.5, запустил из-под standalone-профайлера, периодически снимал снапшоты. На ~1.8 гб упало с E_OUTOFMEMORY. После этого ни закрыть, ни сохранить снапшот не получается, профайлер прибивается только через диспетчер задач.


Привет, спасибо за тест. Я его погоняю у себя, чтобы отполировать работу core. С другой стороны core отработала нехватку паияти и в логах есть:

11:15:52.514 |W| CommandProcessor | OnLogAlert severity=Error hr=8007000E message='Can't allocate memory for profiler core'

Думаю дело во взаимодействии UI и core. Есть шанс починить это в грядущем релизе.
Re[2]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 17.04.15 14:24
Оценка: 18 (1)
Здравствуйте, Tom, Вы писали:

Tom>Интересная мысль, интересная затея.

Tom>Единственное что область применения довольно узкая.

А почему, собственно, на Ваш взгляд узкая?
Я, понимаю, что профилировать перформанс и память — это операция, к сожалению, не частая. Ибо лень, и вообще пока петух не клюнет...
С этим бороться можно только просветительством и все равно будет лень

Но тут то! Есть какой-нибудь TabCollectionVM, есть в нем TabVM c командой Close — написал один раз тест на то, что если после вызова команды Close у, например, последнего табика TabVM`ов больше нет — и спи спокойно.
Или что при переоткрытии документа в программе старого больше нет (какой-нить IDocument в одном экземпляре).
Или алгоритм какой-нить — все у него хорошо, но только за время работы на определенных данных он генерит 17Gb мемори трафика, что приводит к необъяснимым тормозам — хотя по задумке все должно быть O(log N).

Это все примеры из жизни, из чего продукт и родился.

Казалось бы поймал сценарный лик -> написал тест -> радуешься. Все как с юнит тестами на баги.
Да может тут не совсем уж юнит тесты в вакууме, когда тестируется одна сущность, а скорее black/white box тестирование. Но может оно и к лучшему?
В конце концов, не у всех код идеально юнит тестируем, а у те у кого все же 100% TDD — всегда смогут собрать себе необходимый набор компонентов.

Или я не прав? Или реально профилирование — это такой уж совсем крайний, пожарный случай в жизни большинства софта?
Re[4]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 23.04.15 09:38
Оценка: 17 (1)
Здравствуйте, Spinifex, Вы писали:

Про сценарные vs юнит тесты, я поскипал, потому что согласен. Нужны и те и те, вон в соседней ветке эта тема как раз бурлит)

S>Вы сейчас реализовали поддержку первого подхода.

Не согласен!
Давайте я покажу как выглядит сценарный тест dotMemory:

    [Test]
    public void FirstSnapshotAllocationsTest()
    {
      using(var lt = new TransientLifetime())
      {
        var executable = ShellInstance.BuildExecutable<SnapshotsForSimpleAllocations>(lt); // компилируем код
        var allocationsTree = TestedDotMemory.StartProfiling(ProfilerConfigurator.ProfileByApi(executable), lt) // запускаем реальную профиляцию с неким набором параметров
          .AwaitAnalisys()
          .AwaitProfilingSession()
          .AwaitForSnapshots(2) // получили снапшоты
          .First() 
          .OpenAllObjects() // открыли все объекты
          .OpenObjectSetByType() // открыли группировку по типам
          .RunAction(presenter => presenter.AwaiForObjectsByType())
          .OpenSubset(node => node.Kind == ModelEntityKind.OfClass
                              && (node.DisplayName.ToString().Contains(typeof (SnapshotsForSimpleAllocations.MegaTestObject).Name)
                                  || node.DisplayName.ToString().Contains(typeof (SnapshotsForSimpleAllocations.GigaTestObject<>).Name.TrimEnd('`', '1')))) // открыли подсет по определенному условию
          .OpenAllocationsTree() // открыли группировку по аллокациям
          .AwaitAllocationsTree(); // дождались пока аллокации посчитаются

    // ассертим что дм все правильно посчитал
        Assert.That(
          allocationsTree.Sum(_ => _.Statistics.SubTreeAllocatedObjectsCount),
          Is.EqualTo(SnapshotsForSimpleAllocations.GigaTestObjectsInitialCount + SnapshotsForSimpleAllocations.MegaTestObjectsInitialCount));
      }
    }


При этом TestedDotMemory — это не какой-то магический класс, а просто набор статических методов и экстеншенов над интерфейсом VM для выполнения типовых операций.
То есть в этом тесте тестируется один в один тот код, с которым работает пользователь.
Единственное, что не тестируется, так это UI биндинги и прочие лайауты "кнопочек", но это уже и тестер сможет посмотреть.
Да местами нам пришлось пройти через "боль и страдания" и упороться по MVVM, но оно того стоило Ибо нам теперь и сценарные тесты писать легко и перформанс/мемори тесты тоже сюда ложатся на ура.


S>Лично мне кажется, что тестирование (а точнее, наверное, профилирование) памяти лучше ложится на второй подход.

Согласен, но тут вопрос как второй подход имплементить, если в виде "обычных" тестов (см. выше), то все в шоколаде.

S>Причем мне видится так: ставим через инсталятор на виртуальную машину серверную часть, аналогично клиентскую часть. Прогоняем через CodedUI сценарий и смотрим что с памятью. Вот если бы dotMemory выступал как сервис: в какой-то момент указываешь процесс, в какой-то момент получаешь результат.

S>Разве Вам (JetBrains) не проще реализовать такой функционал, чем делать библиотеку для Unit тестирования? ИМХО такой подход найдет не мало своих сторонников.

JetBrains — это не проще, потому что а) нам это не очень нужно, б) это не меньший, а, имхо, гораздо больший геммор по созданию апи сервиса на все случаи жизни.
Кроме того, такой продукт, скорее всего, будет уже платным, что не всем понравится(
В принципе, Вы уже сейчас можете снимать снапшоты со своего кода через Profiling Api, хоть через CodedUI, хоть через как, при этом клиентом выступает сам дотМемори.
Удаленную профиляцию мы тоже поддерживаем.
Чего Вам не хватает, так это консольного репортинга из дм, для того, чтобы автоматически парсить результаты. Возможно мы его реализуем, но это опять же вопрос времени и приоритетов.
Re[2]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 15.04.15 14:33
Оценка: 6 (1)
J>В принципе вещь прикольная и даже местами полезная. Но непонятно, вот вылез у меня в тесте мемлик. OK, как теперь этот тест запустить под дот мемери, чтоб уже детально разобраться, в чем причина?

Спасибо, за отзыв.

Идея была в том, что Вам как бы и не надо запускать под dotMemory, если тест упал по ассерту и вы используете fluent api https://www.jetbrains.com/dotmemory/unit/help/Working_with_Memory.html, то в тестовом аутпуте будет ссылка на сохраненный воркспейс — можно по ней кликнуть и dm его откроет. Что, как, куда и в каких количествах сохранять конфигурируется с помощью атрибута DotMemoryUnit https://www.jetbrains.com/dotmemory/unit/help/Configuring_dotMemory_Unit.html, причем он иерархичен — то есть позволяет настроить значения для ассембли, а потом подтюнить на уровне тест классов и тест методов. Если же вы используете альтернативный подход (https://www.jetbrains.com/dotmemory/unit/help/Alternative_Way_of_Working_with_Memory.html), то вам в конце теста достаточно написать dotMemoryApi.SaveCollectedData(<путь>).
Re[5]: Юнит тестирование "памяти"
От: Sinix  
Дата: 23.04.15 10:32
Оценка: 6 (1)
Здравствуйте, fedor.reznik, Вы писали:

FR>Давайте я покажу как выглядит сценарный тест dotMemory:


Такой вопрос: что в тесте — инфраструктурный код от DotMemoryUnit, а что — собственно тест?
Если весь код кроме Assert.That() — это инфраструктура, то выглядит страшновато.

Есть ещё вариант 2: я тормоз, код — обычный сценарный тест и тут вообще речь не про тестирование с использованием DotMemoryUnit

Если со вторым вариантом угадал — как в DotMemoryUnit будет выглядеть типовой тест для сферического кода в вакууме?
В моём представлении код должен выглядеть примерно так (псевдокод):
var memoryContract = Memory
  .WillNotLeak(threshold: 1kb)
  .NoLohInstances()
  .MaxAllocates(10mb)
  .WarnOnMidlifeCrisis()

using (new AssertionScope(memoryContract))
{
  SomeUseCase();
}


Т.е. отдельно прописываем гарантии для кода (не течём, не замусориваем LOH, дельта по памяти — не больше 10 МБ, код не становится причиной Mid-life crisis), отдельно — запускаем сценарий.

Если у вас будет другой способ — делитесь, интересно
Re[6]: Юнит тестирование "памяти" - CI is available
От: Evgeniy Skvortsov Россия  
Дата: 12.08.15 13:21
Оценка: 6 (1)
Здравствуйте, fedor.reznik, Вы писали:

FR>И это тоже правда, просто все пользователи нашего архива с лончером будут его скачивать с инета.


Так небезопасным файл помечает винда после скачивания, на своей стороне вы ничего сделать не можете.
Это относится ко всем файлам, даже скачанным с сайта майкрософт, так что подписью проблему не решить.
Локально вроде пометку файлов можно отключить через групповые политики, но намного проще кликнуть мышкой и снять блокировку.
Или выкладывать не архив, а инсталлятор. Так как после распаковки все файлы из архива тоже будут небезопасными, а при использовании инсталлятора — нет.
Re[8]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 13.05.15 10:24
Оценка: 4 (1)
Здравствуйте, KRT, Вы писали:

KRT>И ещё немного офтопика Есть планы по поддержке WinPhone? Хотя бы 10 (у них вроде бы теперь общий код с "большой" windows). И может что-то известно про dotTrace, в смысле поддержки винфона 10.


Конкретных планов нет. Последнее исследование показало, что спроса на мобильную профиляцию тоже нет. Может пора провести новое? В общем, пока чисто в теории
Re[9]: Юнит тестирование "памяти"
От: Tom Россия http://www.RSDN.ru
Дата: 20.04.15 15:54
Оценка: +1
FR>Варианты на текущий момент:
FR>1. Берем дотМемори — аттачимся, снимаем сколько угодно снапшотов и препарируем.
Вы шо. Это жеж продакшин! Туда ну никак атачиться низя.

FR>2. Нельзя поставить на продакшен дотМемори из инсталлера? Берем RemoteAgent, копируем на продакшен, запускаем (это экзешничек с wcf сервисом), аттачимся удаленно, см. п.1

FR>Такие варианты совсем не спасают?
Технически можно всё что угодно, практически никто в приличном обществе к продакшину неподпустит.
Народная мудрось
всем все никому ничего(с).
Re[9]: Юнит тестирование "памяти"
От: Tesh США  
Дата: 20.04.15 17:07
Оценка: +1
Здравствуйте, fedor.reznik, Вы писали:

FR>Варианты на текущий момент:

FR>1. Берем дотМемори — аттачимся, снимаем сколько угодно снапшотов и препарируем.
FR>2. Нельзя поставить на продакшен дотМемори из инсталлера? Берем RemoteAgent, копируем на продакшен, запускаем (это экзешничек с wcf сервисом), аттачимся удаленно, см. п.1

FR>Такие варианты совсем не спасают?


Согласен с Tom. Добавлю еще несколько вариантов:
1) сервер отъел слишком много памяти, админы/поддержка/watchdog сделали дамп и перезапустили его;
2) сервер упал, автоматически сделался дамп памяти.
Re[14]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 22.04.15 09:46
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>
S>    static void Main()
S>    {
S>        var l = new List<IntPtr>();
S>        var size = 64 * 1024 * 1024;
S>        for (int i = 0; i < 1024*1024; i++)
S>        {
S>            try
S>            {
S>                l.Add(Marshal.AllocCoTaskMem(size));
S>            }
S>            catch (Exception)
S>            {
S>                size /= 2;
S>            }
S>            Console.WriteLine("{0:N2} kb", Process.GetCurrentProcess().VirtualMemorySize64 / 1024.0);

S>            Thread.Sleep(1000);
S>        }
S>        GC.KeepAlive(l);
S>        Console.WriteLine("Done.");
S>        Console.ReadKey();
S>    }
S>


S>Сборка debug, x86, .net 3.5, запустил из-под standalone-профайлера, периодически снимал снапшоты. На ~1.8 гб упало с E_OUTOFMEMORY.

Ситуация ясна. Вы отъели всю нативную память таким образом. А профайлер на стороне приложения нативный и ему стало плоховато.

S>После этого ни закрыть, ни сохранить снапшот не получается, профайлер прибивается только через диспетчер задач.


Это баг, все равно должна быть возможность корректно завершиться. Спасибо! Будем разбираться.
Re[3]: Юнит тестирование "памяти"
От: Spinifex Россия https://architecture-cleaning.ru/
Дата: 23.04.15 06:00
Оценка: +1
Здравствуйте, fedor.reznik, Вы писали:

S>>Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.

S>>Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.

FR>Вообще говоря, профилировать имеет смысл только Release версии. Хотя ваш пример несколько искусственный и в реальности таких засад будет меньше, но тем не менее.


Возможно два варианта:
1. Мы пишем юнит тесты на каждый класс.
2. Мы пишем что-то вроде нагрузочных тестов на сценарии и смотрим чтобы в этом сценарии память расходовалась в приемлемых объемах.

Плюсы первого подхода:

а) можно быстро понять что конкретно сломалось; б) быстрые.
Минусы первого подхода:
а) зависят от внутреннего дизайна кода — в случае рефакторинга нужно будем менять кучу тестов. б) банально больше строк кода с тестами в сравнении со вторым подходом.

Плюсы второго подхода:

а) т.к. привязаны к сценариям, любой член команды может понять что сломалось (тестер, менеджер и т.п.; особенно если это реализовано с помощью Specflow). Все понимают, что допустим в сценарии "Создание резервной копии структуры библиотеки" в этой версии софта расходуется память; б) кода самих тестов заметно меньше; в) нет зависимости от внутренней организации кода — нам абсолютно без разницы какие классы и с кем взаимодействуют, где и в каком классе теперь хранятся данные, главное чтобы сценарий в целом не расходовал память. Т.е. в случае рефакторинга тесты не переписываются; г)
Минусы второго подхода:
а) Разработчику нужно отлаживаться, чтобы понять что именно привело к падению теста; б) медленные.

Вы сейчас реализовали поддержку первого подхода. Лично мне кажется, что тестирование (а точнее, наверное, профилирование) памяти лучше ложится на второй подход. Причем мне видится так: ставим через инсталятор на виртуальную машину серверную часть, аналогично клиентскую часть. Прогоняем через CodedUI сценарий и смотрим что с памятью. Вот если бы dotMemory выступал как сервис: в какой-то момент указываешь процесс, в какой-то момент получаешь результат.

Разве Вам (JetBrains) не проще реализовать такой функционал, чем делать библиотеку для Unit тестирования? ИМХО такой подход найдет не мало своих сторонников.
Отредактировано 23.04.2015 6:01 Nikita Lyapin . Предыдущая версия .
Re[10]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 13.05.15 11:58
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Вот кстати хорошее предложение В мобильных девайсах, особенно с ограничениями типа 11 MB на background agent за памятью точно надо следить.


Предложение — огонь, да. Только, по факту, когда у нас была поддержка винмобайл, ей пользовались 0.1% людей Плюс, как я уже говорил маркетинговые исследования говорят, что такая профиляция не нужна. Может и врут)

З.Ы.: я то только за, но не хочется тратить время в пустую.
Re: Юнит тестирование "памяти"
От: Jack128  
Дата: 15.04.15 14:24
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

Как раз на прошлой неделе побывал эту штуку. В принципе вещь прикольная и даже местами полезная. Но непонятно, вот вылез у меня в тесте мемлик. OK, как теперь этот тест запустить под дот мемери, чтоб уже детально разобраться, в чем причина?
Re: Юнит тестирование "памяти"
От: baranovda Российская Империя  
Дата: 15.04.15 23:12
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Всем доброго дня!

FR>Мы написали фреймворк для юнит тестирования памяти .Net приложений. Хотелось бы обсудить насколько это может быть интересно и вообще получить фидбэк по функциональности.

Дурацкий вопрос можно? Ловятся только утечки .Net или unmanaged тоже может?
Отредактировано 15.04.2015 23:17 α . Предыдущая версия .
Re[2]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 16.04.15 10:18
Оценка:
Здравствуйте, baranovda, Вы писали:

B>Дурацкий вопрос можно? Ловятся только утечки .Net или unmanaged тоже может?


Unmanaged не может( Но имею встречный вопрос: по каким критериям хотелось бы кверить куски unmanged память из юнит тестов написанных на .Net? А то она ведь совсем "разная" и просто мерить ее объем, имхо, большого смысла не имеет.
Re[6]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 16.04.15 13:38
Оценка:
Здравствуйте, Sinix, Вы писали:

Спасибо, за дельный фидбэк

Идея про тесты на иммутабельность, в частности, и состояния объекта, в общем, очень интересная.

Будем мозговать.
Отредактировано 16.04.2015 13:38 fedor.reznik . Предыдущая версия .
Re: Юнит тестирование "памяти"
От: Tom Россия http://www.RSDN.ru
Дата: 17.04.15 13:55
Оценка:
Интересная мысль, интересная затея.
Единственное что область применения довольно узкая.
Народная мудрось
всем все никому ничего(с).
Re[3]: Юнит тестирование "памяти"
От: Tesh США  
Дата: 19.04.15 19:45
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Или я не прав? Или реально профилирование — это такой уж совсем крайний, пожарный случай в жизни большинства софта?


Не скажу за весь софт, но мне за 8 лет приходилось заниматься профилированием раза 2-3.
И каждый раз это было вызвано наличием какой-то проблемы.

Если нагрузочное тестирование, либо боевая эксплуатация не выявили проблем, то смысл что-то профилировать? Выглядит как преждевременная оптимизация.
Отредактировано 19.04.2015 19:45 Tesh . Предыдущая версия .
Re[4]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 08:24
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Не скажу за весь софт, но мне за 8 лет приходилось заниматься профилированием раза 2-3.

T>И каждый раз это было вызвано наличием какой-то проблемы.

T>Если нагрузочное тестирование, либо боевая эксплуатация не выявили проблем, то смысл что-то профилировать? Выглядит как преждевременная оптимизация.


Да, это правда. В типичных случаях, что-то заранее профилировать никто не будет.

С другой стороны, я участвовал как минимум в трех коммерчески успешных проектах, в которых, не было тестов. Совсем. От слова вообще.
Значит ли это, что тесты писать — это преждевременно себя напрягать? Наверное, нет.

Далее, если проблема возникла, то обычно ее фиксить дорого (потому что надо срочно) и, за частую, поздно.
Поэтому очевидные сценарии, имхо, имеет смысл профилировать перед каждым релизом — Вы же не выпускаете продукт без тестирования?

И dotMemoryUnit — это такое средство автоматизировать этот процесс, а вовсе не yet another profiler)
И именно в этом смысле, как мне кажется, он имеет гораздо более широкое применение.
Re[5]: Юнит тестирование "памяти"
От: Tesh США  
Дата: 20.04.15 13:28
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>С другой стороны, я участвовал как минимум в трех коммерчески успешных проектах, в которых, не было тестов. Совсем. От слова вообще.

FR>Значит ли это, что тесты писать — это преждевременно себя напрягать? Наверное, нет.

Если там не было тестов, значит их наличие не было экономически обосновано. Тесты не бесплатны и требуют время как на написание, так и на поддержку.

FR>Далее, если проблема возникла, то обычно ее фиксить дорого (потому что надо срочно) и, за частую, поздно.

FR>Поэтому очевидные сценарии, имхо, имеет смысл профилировать перед каждым релизом — Вы же не выпускаете продукт без тестирования?

Для этого существуют приемочное и нагрузочное тестирования.

FR>И dotMemoryUnit — это такое средство автоматизировать этот процесс, а вовсе не yet another profiler)

FR>И именно в этом смысле, как мне кажется, он имеет гораздо более широкое применение.

Обычные тесты помогают убедиться в том, что код работает корректно с точки зрения бизнес-логики или архитектуры. Это по идее чаще востребовано, чем покрытие кода тестами для ответа на вопрос "а не течет ли чего" или "эффективно ли выделяется память". Такие тесты тоже могут пригодиться, но не думаю что они будут столь же широко распространены как тесты логики.
Отредактировано 20.04.2015 13:33 Tesh . Предыдущая версия . Еще …
Отредактировано 20.04.2015 13:32 Tesh . Предыдущая версия .
Re[5]: Юнит тестирование "памяти"
От: Tesh США  
Дата: 20.04.15 13:31
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

Немного оффтопика.
Для dotMemory планируется добавление возможности загрузки дампов памяти?
Re[6]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 13:33
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Для этого существуют приемочное и нагрузочное тестирования.


Так вот предлагается частично автоматизировать это приемочно/нагрзочное тестрирование
Re[6]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 13:39
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Здравствуйте, fedor.reznik, Вы писали:


T>Немного оффтопика.

T>Для dotMemory планируется добавление возможности загрузки дампов памяти?

Планируется: https://youtrack.jetbrains.com/issue/DMRY-8.

Постоянно рученек не хватает((

Кстати, раз уж оффтоп пошел, а какой для Вас основной юзкейс для дампов?
Или перефразируя — в каких условиях Вы не можете обойтись dm снапшотами, которые, а это уже очевидно на данном этапе исследований, будут содержать гораздо больше информации для анализа?
Re[3]: Юнит тестирование "памяти"
От: Tom Россия http://www.RSDN.ru
Дата: 20.04.15 15:16
Оценка:
FR>А почему, собственно, на Ваш взгляд узкая?
Потому что лики на клиентской стороне мало кому нужно профилировать а на порядочном state less сервере ликом неоткуда взяться

FR>Или я не прав? Или реально профилирование — это такой уж совсем крайний, пожарный случай в жизни большинства софта?

Профилирование разное бывает.
Народная мудрось
всем все никому ничего(с).
Re[7]: Юнит тестирование "памяти"
От: Tom Россия http://www.RSDN.ru
Дата: 20.04.15 15:20
Оценка:
FR>Постоянно рученек не хватает((
FR>Кстати, раз уж оффтоп пошел, а какой для Вас основной юзкейс для дампов?
FR>Или перефразируя — в каких условиях Вы не можете обойтись dm снапшотами, которые, а это уже очевидно на данном этапе исследований, будут содержать гораздо больше информации для анализа?

ИМХО отсутствие дампов — болшая проблема.
Мой кейз — смотрим состояние продакшин сервера, видим процесс подозрительно много памяти ест.
Делаем дамп и препарируем.
Народная мудрось
всем все никому ничего(с).
Re[8]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 15:48
Оценка:
Здравствуйте, Tom, Вы писали:

Tom>ИМХО отсутствие дампов — болшая проблема.

Я согласен, что проблема. Вопрос в ее масштабах.

Tom>Мой кейз — смотрим состояние продакшин сервера, видим процесс подозрительно много памяти ест.

Tom>Делаем дамп и препарируем.

Варианты на текущий момент:
1. Берем дотМемори — аттачимся, снимаем сколько угодно снапшотов и препарируем.
2. Нельзя поставить на продакшен дотМемори из инсталлера? Берем RemoteAgent, копируем на продакшен, запускаем (это экзешничек с wcf сервисом), аттачимся удаленно, см. п.1

Такие варианты совсем не спасают?
Re[10]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 16:11
Оценка:
Здравствуйте, Tom, Вы писали:

FR>>Варианты на текущий момент:

FR>>1. Берем дотМемори — аттачимся, снимаем сколько угодно снапшотов и препарируем.
Tom>Вы шо. Это жеж продакшин! Туда ну никак атачиться низя.

А аттачиться нельзя, потому что замедляет или политики безопасности? А дамп при этом можно?

FR>>2. Нельзя поставить на продакшен дотМемори из инсталлера? Берем RemoteAgent, копируем на продакшен, запускаем (это экзешничек с wcf сервисом), аттачимся удаленно, см. п.1

Tom>Технически можно всё что угодно, практически никто в приличном обществе к продакшину неподпустит.

Но при этом у Вас очевидно есть возможность туда пойти и снять дамп, что несколько нарушает фразу "никто в приличном обществе к продакшину неподпустит"

В теории есть еще третий вариант, мы сейчас обкатываем так называемый self-profiling API, который позволяет оттопырить из приложения условно кнопку — дай мне перформанс снапшот, дай мне мемори снапшот,
на выходе получается файл, который умеет открывать dotMemory или dotTrace, соответственно.
А это уже не сильно отличается от "зайти и снять дамп".
В данный момент такая функциональность доступна по запросу.

Вы не поймите меня не правильно, дампы мы и сами хотим сделать.
Просто хочется понять можно ли помочь большинству тех, кто хочет дампы, уже существующими средствами.
Re[12]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 16:43
Оценка:
Здравствуйте, Tom, Вы писали:

Ясно, понятно
Еще один "+" в копилочку сделать дампы, еще один "-" в сторону теории, что xcopy exe всегда можно запустить.
Спасибо.
Re[10]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 17:09
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Согласен с Tom. Добавлю еще несколько вариантов:

T>1) сервер отъел слишком много памяти, админы/поддержка/watchdog сделали дамп и перезапустили его;
T>2) сервер упал, автоматически сделался дамп памяти.

Угу, спасибо!
Re[7]: Юнит тестирование "памяти"
От: Tesh США  
Дата: 20.04.15 17:18
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Так вот предлагается частично автоматизировать это приемочно/нагрзочное тестрирование


Так или иначе все равно здорово, что вы этим занимаетесь.
Даже если оно не будет широко использоваться, возможно эти наработки станут ступенью на пути к чему-то еще более интересному (по аналогии с фундаментальными науками)
Re[8]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 20.04.15 17:20
Оценка:
Здравствуйте, Tesh, Вы писали:

T>Здравствуйте, fedor.reznik, Вы писали:


FR>>Так вот предлагается частично автоматизировать это приемочно/нагрзочное тестрирование


T>Так или иначе все равно здорово, что вы этим занимаетесь.

T>Даже если оно не будет широко использоваться, возможно эти наработки станут ступенью на пути к чему-то еще более интересному (по аналогии с фундаментальными науками)

Вашими бы словами
Re[11]: Юнит тестирование "памяти"
От: Sinix  
Дата: 20.04.15 19:40
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Угу, спасибо!

Ещё один юзкейз, буквально на прошлой неделе: outofmemoryexception в стороннем компоненте.

Запускаем процесс под дотмемори, воспроизводим, пытаемся сделать снапшот, облом — компонент под x86, АП почти полностью отожрано, фиаско Код ошибки в профайлере не запомнил, не до того было, если сильно надо — попробую воспроизвести. Позже из спортивного интереса прогнал триалом ants profiler — итог тот же.

VS 2013 + memory dumps — наше всё, короче.
Re[12]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 21.04.15 11:05
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Запускаем процесс под дотмемори, воспроизводим, пытаемся сделать снапшот, облом — компонент под x86, АП почти полностью отожрано, фиаско Код ошибки в профайлере не запомнил, не до того было, если сильно надо — попробую воспроизвести. Позже из спортивного интереса прогнал триалом ants profiler — итог тот же.


Если будет время воспроизведите, пожалуйста, сразу с логами:
How to get Core logs

А потом любым удобным вам способом расшарьте логи нам. Как вариант через ftp://ftp.intellij.net/.uploads/

Заранее, спасибо.
Re[13]: Юнит тестирование "памяти"
От: Sinix  
Дата: 21.04.15 11:19
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Если будет время воспроизведите, пожалуйста, сразу с логами:

Ок, постараюсь на этой неделе.
Re: Юнит тестирование "памяти"
От: Spinifex Россия https://architecture-cleaning.ru/
Дата: 22.04.15 06:27
Оценка:
Интересная вещь, иногда нужно зафиксировать результаты работ по оптимизации памяти.
Решил попробовать и набросал простейший пример (см. ниже).
Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.
Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.

На мой взгляд было бы удобным иметь возможность получать размер не только объекта, но и все его ссылок.
Когда планируется интеграция с CI?

public class Some
{
    private int d;
}

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void TestMethod1()
    {
        var b1 = new Some();
        var b2 = new Some(); 
         
        var memoryCheckPoint1 = dotMemory.Check(
              memory =>
                   {
                        Assert.AreEqual(2, memory.GetObjects(where => where.Type.Is<Some>()).ObjectsCount, "Неверное количество объектов");
                    }
                );
            
        GC.Collect();
            
        var memoryCheckPoint2 = dotMemory.Check(
                    memory =>
                    {
                        Assert.AreEqual(2, memory.GetDifference(memoryCheckPoint1).GetSurvivedObjects().GetObjects(where => where.Type.Is<Some>()).ObjectsCount, "Неверное количество объектов");
                    }
                );
        }
    }
Re[13]: Юнит тестирование "памяти"
От: Sinix  
Дата: 22.04.15 08:26
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Если будет время воспроизведите, пожалуйста, сразу с логами:


В логах ничего толком нет, воспроизвёл кодом:
    static void Main()
    {
        var l = new List<IntPtr>();
        var size = 64 * 1024 * 1024;
        for (int i = 0; i < 1024*1024; i++)
        {
            try
            {
                l.Add(Marshal.AllocCoTaskMem(size));
            }
            catch (Exception)
            {
                size /= 2;
            }
            Console.WriteLine("{0:N2} kb", Process.GetCurrentProcess().VirtualMemorySize64 / 1024.0);

            Thread.Sleep(1000);
        }
        GC.KeepAlive(l);
        Console.WriteLine("Done.");
        Console.ReadKey();
    }


Сборка debug, x86, .net 3.5, запустил из-под standalone-профайлера, периодически снимал снапшоты. На ~1.8 гб упало с E_OUTOFMEMORY. После этого ни закрыть, ни сохранить снапшот не получается, профайлер прибивается только через диспетчер задач.
Re[2]: Юнит тестирование "памяти"
От: Ed.ward Россия  
Дата: 22.04.15 11:28
Оценка:
Здравствуйте, Spinifex, Вы писали:

S>Интересная вещь, иногда нужно зафиксировать результаты работ по оптимизации памяти.

S>Решил попробовать и набросал простейший пример (см. ниже).
S>Под debug он проходит, а под релизом сразу падает. Что естественно b1 и b2 — не используются в коде.
S>Не совсем очевидный нюанс при таком подходе: у нас появляется зависимость от конфигурации билда.

Здесь вы тестируете тест, отсюда и проблема. Если вы напишете простейшую инкапсулированную логику и протестируете её, проблема исчезнет.
Оптимизации в Release конфигурации действительно могут освободить пременную раньше выхода за зону видимости, но поймать это тестом без многопоточности нельзя.

Ed.ward
Re[7]: Юнит тестирование "памяти"
От: Sinix  
Дата: 23.04.15 12:53
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

S>>Есть ещё вариант 2: я тормоз, код — обычный сценарный тест и тут вообще речь не про тестирование с использованием DotMemoryUnit

FR>Эм... Ну как бы да, в данном случае вариант два
FR>В целом, и он и правда будет выглядеть примерно так, с поправкой на то, что, как Вы помните, у нас сейчас нет таких "супер хелперов".
Ок, принято. Спасибо!
Re[5]: Юнит тестирование "памяти"
От: Spinifex Россия https://architecture-cleaning.ru/
Дата: 27.04.15 15:37
Оценка:
Ок, спасибо за ответ.
Сейчас как раз разбирался с дефектом, заведенным через CodedUI. Наше клиентское десктопное приложение, написанное на WPF текло по памяти. Причем не слабо так...
В результате разбора полетов обнаружил вот такую вот вещь: Здесь

Т.е. если вы используете Automation API (это все продукты: White, MS CodedUI, Ranorex и т.п.) у вас приложение под тестами будет гарантировано "протекать".
Супер! На варианте сценарных тестов можно ставить крест. Ну почти...
Отредактировано 27.04.2015 15:38 Nikita Lyapin . Предыдущая версия .
Re: Юнит тестирование "памяти"
От: VladCore  
Дата: 12.05.15 22:10
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Всем доброго дня!


FR>Что умеет фреймворк:


FR>- выбирать объекты по типам, интерфейсам, неймспейсам, поколениям

FR>- сравнивать срезы памяти — выбирать новые объекты, умершие, выжившие
FR>- добывать информацию о мемори траффике, в том числе поддерживаются ассерты на траффик с помощью атрибутов.
FR>- у любой выборки объектов можно посмотреть количество памяти и объектов

Спасибо, но если это всё попытаться визуализировать, то за 5 минут работы тестов может набраться миллиарды терабайт инфы.
Есть гайд как память тестировать с вашим фреймворком?
Re: Юнит тестирование "памяти"
От: VladCore  
Дата: 12.05.15 22:21
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>Всем доброго дня!


FR>Фреймворк распространяется в виде нугет пакета (https://www.nuget.org/packages/JetBrains.DotMemoryUnit/) и совершенно бесплатен. Все что необходимо иметь это юниттест раннер от джетбрейнса, то есть иметь установленный ReSharper 9.1 или dotCover 3.1.

FR>Отдельный "запускатель" таких тестов нами запланирован на будущее.

Как всё интересно и непонятно.

К примеру, как это работает? Ваш тест-раннер подключает какой-то ваш профайлер когда в тестах используется референс на ваш пакедж?
Если так какой футпринт по производительности и использованию памяти?
И что будет с ассертами в других тест-раннерах, например под теми линаксами?

Эксьюз май инглиш.
Re[2]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 13.05.15 09:47
Оценка:
Здравствуйте, VladCore, Вы писали:

VC>Спасибо, но если это всё попытаться визуализировать, то за 5 минут работы тестов может набраться миллиарды терабайт инфы.

VC>Есть гайд как память тестировать с вашим фреймворком?

Я честно, не очень понял вашего вопроса. Я в начальном посте приводил ссылки на документацию. Что касается 5 минут и терабайта инфы... ну как вам сказать реальные приложения и часами под дотМемори профилируются и как-то справляемся
Re[2]: Юнит тестирование "памяти"
От: fedor.reznik  
Дата: 13.05.15 09:55
Оценка:
Здравствуйте, VladCore, Вы писали:

VC>К примеру, как это работает? Ваш тест-раннер подключает какой-то ваш профайлер когда в тестах используется референс на ваш пакедж?

Да совершенно верно, тесты запускаются под "движком" dotMemory. Только одного референса не достаточно — надо запускать тесты как Run Unit Tests under dotMemory Unit из меню юнит-тестов.

VC>Если так какой футпринт по производительности и использованию памяти?

По производительности тяжело сказать — зависит от сложности исполняемого кода. Но я бы не стал в таких тестах измерять еще и производительность.
Что касается памяти — то мы старались минимизировать импакт, хотя, при должной дотошности, наши объекты там можно будет найти

VC>И что будет с ассертами в других тест-раннерах, например под теми линаксами?

Если вы используете fluent api: dotMemory.Check(where => ...), то все вызовы dotMemory.Check — будут проигнорены. Если вы используете альтернативный вариант dotMemoryApi, то вам надо в тестах проверять флажок
dotMemoryApi.IsEnabled.
Отредактировано 13.05.2015 10:30 fedor.reznik . Предыдущая версия .
Re[9]: Юнит тестирование "памяти"
От: Sinix  
Дата: 13.05.15 11:53
Оценка:
Здравствуйте, fedor.reznik, Вы писали:


FR>Конкретных планов нет. Последнее исследование показало, что спроса на мобильную профиляцию тоже нет. Может пора провести новое? В общем, пока чисто в теории


Вот кстати хорошее предложение В мобильных девайсах, особенно с ограничениями типа 11 MB на background agent за памятью точно надо следить.
Re[2]: Юнит тестирование "памяти" - CI is available
От: Evgeniy Skvortsov Россия  
Дата: 12.08.15 12:57
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR>BTW, если кто знает как заставить винду считать архив безопасным — буду очень благодарен


Правый клик на файле — свойства — разблокировать.
Re[3]: Юнит тестирование "памяти" - CI is available
От: fedor.reznik  
Дата: 12.08.15 13:00
Оценка:
Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>Здравствуйте, fedor.reznik, Вы писали:


FR>>BTW, если кто знает как заставить винду считать архив безопасным — буду очень благодарен


ES>Правый клик на файле — свойства — разблокировать.



Про это-то я выше написал, спасибо. Но именно в этом действии и проблема. Я перефразирую свой вопрос тогда — чтобы бы такого сделать и, главное как, с zip архивом при его формировании, чтобы винда ВСЕГДА считала его безопасным? То есть можно ли как-то так хитро подписать zip?
Re[4]: Юнит тестирование "памяти" - CI is available
От: Evgeniy Skvortsov Россия  
Дата: 12.08.15 13:08
Оценка:
Здравствуйте, fedor.reznik, Вы писали:

FR> Про это-то я выше написал, спасибо. Но именно в этом действии и проблема. Я перефразирую свой вопрос тогда — чтобы бы такого сделать и, главное как, с zip архивом при его формировании, чтобы винда ВСЕГДА считала его безопасным? То есть можно ли как-то так хитро подписать zip?


Странно, обычно небезопасным файл помечается если скачать его с инета. А что бы при создании на локальном компе он сразу был небезопасен, с таким не сталкивался.
Re[5]: Юнит тестирование "памяти" - CI is available
От: fedor.reznik  
Дата: 12.08.15 13:11
Оценка:
Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>Странно, обычно небезопасным файл помечается если скачать его с инета. А что бы при создании на локальном компе он сразу был небезопасен, с таким не сталкивался.


И это тоже правда, просто все пользователи нашего архива с лончером будут его скачивать с инета.
Re[7]: Юнит тестирование "памяти" - CI is available
От: fedor.reznik  
Дата: 12.08.15 13:23
Оценка:
Здравствуйте, Evgeniy Skvortsov, Вы писали:

ES>Так небезопасным файл помечает винда после скачивания, на своей стороне вы ничего сделать не можете.

ES>Это относится ко всем файлам, даже скачанным с сайта майкрософт, так что подписью проблему не решить.
ES>Локально вроде пометку файлов можно отключить через групповые политики, но намного проще кликнуть мышкой и снять блокировку.
ES>Или выкладывать не архив, а инсталлятор. Так как после распаковки все файлы из архива тоже будут небезопасными, а при использовании инсталлятора — нет.

Спасибо! Жаль, этого я и боялся.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.