Соглашусь, мы имеем дело с «дырявой» абстракцией, ведь на уровне тестов, знающих только про названия кнопочек UI, мы начинаем оперировать именами классов кода приложения. Явное неудобство этого заключается в том, что переименовывая класс, необходимо не забыть поправить строчку в тесте. По поводу поддержки проверок утечек в общем плейлисте UI тестов — в минимальном варианте можно перед выходом из приложения по окончании всех тестов проверять, что все тяжелые объекты, которые должны быть в памяти максимум в одном экземпляре одновременно, проходят эту проверку. Примерами таких объектов могут быть view model от окон, которые физически невозможно открыть несколько одновременно.
Вы правы, модульным (unit) такой тест не является (но мы его таким нигде и не называли).
Вообще, перечисленные вами тестовые фреймворки никак не диктуют само содержание теста. Тест, написанный с их помощью, может быть модульным, интеграционным или даже UI тестом. Мы, например, пишем UI тесты на nunit в связке с Winium.Cruciatus. И посреди этих тестов вставляем проверки на утечки памяти, как описано в статье.
Добрый день! Мы в курсе проблемы, ждем фикса от разработчика драйвера, использующегося в нашей системе. Обойти проблему на данный момент можно отключив опцию Secure Boot в BIOS.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Вообще, перечисленные вами тестовые фреймворки никак не диктуют само содержание теста. Тест, написанный с их помощью, может быть модульным, интеграционным или даже UI тестом. Мы, например, пишем UI тесты на nunit в связке с Winium.Cruciatus. И посреди этих тестов вставляем проверки на утечки памяти, как описано в статье.