Comments 12
Requirements: Microsoft visual C++ 2010 Redistributable installedЯ так понимаю, что в .Net Core под Linux работать не будет? А жаль!
Спасибо.
По моему, это unit test'ом не называется: профайлинг процесса, как профайлинг (но техника интересная, конечно). Можно наверное назвать автоматическим профайлингом с проверкой постусловий. В юнит-тест (xunit, nunit, mstest) фреймоворки такое не запихаешь.
using (var session = Profiler.AttachToProcess("LeakingApp")) { /*...*/ ;}По моему, это unit test'ом не называется: профайлинг процесса, как профайлинг (но техника интересная, конечно). Можно наверное назвать автоматическим профайлингом с проверкой постусловий. В юнит-тест (xunit, nunit, mstest) фреймоворки такое не запихаешь.
Вы правы, модульным (unit) такой тест не является (но мы его таким нигде и не называли).
Вообще, перечисленные вами тестовые фреймворки никак не диктуют само содержание теста. Тест, написанный с их помощью, может быть модульным, интеграционным или даже UI тестом. Мы, например, пишем UI тесты на nunit в связке с Winium.Cruciatus. И посреди этих тестов вставляем проверки на утечки памяти, как описано в статье.
Вообще, перечисленные вами тестовые фреймворки никак не диктуют само содержание теста. Тест, написанный с их помощью, может быть модульным, интеграционным или даже UI тестом. Мы, например, пишем UI тесты на nunit в связке с Winium.Cruciatus. И посреди этих тестов вставляем проверки на утечки памяти, как описано в статье.
Да вы правы, я небрежен. regression и unit не одно и тоже.
Однако вопрос о том насколько это автоматизированнае профилирование удобно держать в общем плейлисте. Ухаживание за процессами в которых живут объекты и в котором автопрофилирование исполняется — чистый abstaction leak и требует особого внимания. Впрочем у меня самого в общих плей листах — есть проверки на то что число объектов в глобальном пуле не растет (происходит переиспользование) — тоже abstraction leak, так как держится в уме некая уверенность что другие тесты на результат не влияют (хотя могут).
Однако вопрос о том насколько это автоматизированнае профилирование удобно держать в общем плейлисте. Ухаживание за процессами в которых живут объекты и в котором автопрофилирование исполняется — чистый abstaction leak и требует особого внимания. Впрочем у меня самого в общих плей листах — есть проверки на то что число объектов в глобальном пуле не растет (происходит переиспользование) — тоже abstraction leak, так как держится в уме некая уверенность что другие тесты на результат не влияют (хотя могут).
Соглашусь, мы имеем дело с «дырявой» абстракцией, ведь на уровне тестов, знающих только про названия кнопочек UI, мы начинаем оперировать именами классов кода приложения. Явное неудобство этого заключается в том, что переименовывая класс, необходимо не забыть поправить строчку в тесте. По поводу поддержки проверок утечек в общем плейлисте UI тестов — в минимальном варианте можно перед выходом из приложения по окончании всех тестов проверять, что все тяжелые объекты, которые должны быть в памяти максимум в одном экземпляре одновременно, проходят эту проверку. Примерами таких объектов могут быть view model от окон, которые физически невозможно открыть несколько одновременно.
А для UnitTest-ов есть inproc вариант?
Вполне можно скрестить с автоматизацией тестирования WPF via SpecFlow, например… И иметь что-то типа UI тестов — но при этом по памяти… ) Хм… А круто ))
UFO just landed and posted this here
Sign up to leave a comment.
Регрессионные тесты на утечки памяти, или как написать memory profiler для .NET приложений