Тестирование представления в приложении MVFM WPF

Question

Я только начинаю в захватывающем мире разработки WPF, будучи разработчиком C++ уже много лет.

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

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

Это все хорошо и хорошо, и аккуратно отделяет тестирование логики приложения от пользовательского интерфейса приложения. НО, он не дает решения для собственно тестирования самого пользовательского интерфейса. Хотя представление, как правило, будет содержать очень мало логики, оно все равно будет содержать огромное количество ошибок различного рода.

Каково современное состояние при тестировании самого представления?

Благодаря Том

Answer 1

Это всегда палка о двух концах. Я вижу это как попытку схватить низко висящие фрукты и построить оттуда.

Теоретически пурист MVVM заявил бы, что абсолютно нет логики в коде View. Использование Призмы, например, может помочь облегчить это, а также другие различные рамки. Так что, исходя из этого угла, он начинает доходить до точки отсутствия логики, существующей в представлении ... достаточно справедливо, будем ли мы начинать тестирование привязок? Вы могли бы, однако, в зависимости от размера приложения, какова отдача от этих инвестиций?

Что я думаю, это сводится к тому, где вы рисуете линию? Например, даже если вы тестируете View, вы, скорее всего, будете подключаться к коду, тогда вы будете тестировать белые ящики. Затем вы можете утверждать, что угол черного ящика является допустимым только для проверки без внутренних перехватов. Вы можете видеть, что это становится круговым кошмаром.

В целом я сосредоточился на больших товарах и отправился оттуда, проверив, что было возможно с выделенным временем.

Подумайте об этом таким образом ... с пользовательским интерфейсом вы можете начать это фиаско тестирования окраски на каждой кнопке вместе с местом размещения и т. Д. Это глупо для меня. Автоматизируйте большую часть тестирования пользовательского интерфейса на уровне Model, ViewModel, и если вы так хотите проверить привязки вашего представления. Другое дело, что я предлагаю специальные усилия вручную, которые каждый разработчик пользовательского интерфейса должен делать на своей рабочей станции.

Answer 2

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