Открыть список
Как стать автором
Обновить

Комментарии 12

Requirements: Microsoft visual C++ 2010 Redistributable installed
Я так понимаю, что в .Net Core под Linux работать не будет? А жаль!
Этого требует managed injector, мы рассмотрим варианты решения.
Спасибо.

using (var session = Profiler.AttachToProcess("LeakingApp")) { /*...*/ ;}

По моему, это unit test'ом не называется: профайлинг процесса, как профайлинг (но техника интересная, конечно). Можно наверное назвать автоматическим профайлингом с проверкой постусловий. В юнит-тест (xunit, nunit, mstest) фреймоворки такое не запихаешь.

Вы правы, модульным (unit) такой тест не является (но мы его таким нигде и не называли).
Вообще, перечисленные вами тестовые фреймворки никак не диктуют само содержание теста. Тест, написанный с их помощью, может быть модульным, интеграционным или даже UI тестом. Мы, например, пишем UI тесты на nunit в связке с Winium.Cruciatus. И посреди этих тестов вставляем проверки на утечки памяти, как описано в статье.
Да вы правы, я небрежен. regression и unit не одно и тоже.
Однако вопрос о том насколько это автоматизированнае профилирование удобно держать в общем плейлисте. Ухаживание за процессами в которых живут объекты и в котором автопрофилирование исполняется — чистый abstaction leak и требует особого внимания. Впрочем у меня самого в общих плей листах — есть проверки на то что число объектов в глобальном пуле не растет (происходит переиспользование) — тоже abstraction leak, так как держится в уме некая уверенность что другие тесты на результат не влияют (хотя могут).
Соглашусь, мы имеем дело с «дырявой» абстракцией, ведь на уровне тестов, знающих только про названия кнопочек UI, мы начинаем оперировать именами классов кода приложения. Явное неудобство этого заключается в том, что переименовывая класс, необходимо не забыть поправить строчку в тесте. По поводу поддержки проверок утечек в общем плейлисте UI тестов — в минимальном варианте можно перед выходом из приложения по окончании всех тестов проверять, что все тяжелые объекты, которые должны быть в памяти максимум в одном экземпляре одновременно, проходят эту проверку. Примерами таких объектов могут быть view model от окон, которые физически невозможно открыть несколько одновременно.
А для UnitTest-ов есть inproc вариант?
Для inproc я бы посоветовал использовать dotMemory Unit. Он бесплатный и функционала в нем сильно больше.
Вполне можно скрестить с автоматизацией тестирования WPF via SpecFlow, например… И иметь что-то типа UI тестов — но при этом по памяти… ) Хм… А круто ))
Если сделаете, поделитесь опытом. Будет весьма интересно почитать.

В проекте на GitHub нет файлов ManagedInjector.exe, ManagedInjector64-4.0.dll, ManagedInjector32-4.0.dll, тогда как в структуру проекта они включены.
Где их можно взять? Это то, что в поставке Snoop называется ManagedInjectorLauncher64-4.0.exe?

Недоглядел, прошу прощения. Нужные файлы добавлены. А так да, взяты из Snoop.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
ascon.ru
Численность
501–1 000 человек
Дата регистрации

Блог на Хабре