Как правильно протестировать представление в MVVM?

Я видел несколько статей о модульном тестировании моделей представлений в MVVM и о том, как сами тесты являются потребителями моделей представлений, тестируя функциональность модели представления и модели. Тем не менее, мне остается задаться вопросом, как я буду тестировать представления (UI), чтобы убедиться, что они правильно подключены к моим моделям представлений. Я не хочу писать тест, который, например, нажимает кнопку, чтобы убедиться, что что-то записано в базу данных, так как это эффективно проверяет мою виртуальную машину, что я уже сделал.

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

Это возможно? благодаря.


mvvm c# wpf xaml
person HAdes    schedule 10.08.2009    source источник
comment
IMO, если ваша логика пользовательского интерфейса правильно отделена от остальной части вашего приложения, следуя шаблону MVVM, MVP, MVC или аналогичному шаблону, я всегда чувствовал, что не важно тестировать пользовательский интерфейс, кроме как с некоторым общим приемочным тестированием.   -  person Chris Marisic    schedule 10.08.2009
comment
Крис, без теста пользовательского интерфейса как можно быть уверенным, что любые внесенные изменения не испортят существующую функциональность. то есть удаление команды на кнопке, из-за чего она больше не сохраняется.   -  person HAdes    schedule 10.08.2009
comment
Вы все равно собирались протестировать пользовательский интерфейс, верно? Из-за визуальных и эстетических глюков? При этом вы, вероятно, обнаружите ошибки и неправильные ответы. Мой аргумент заключается в том, что пользовательские интерфейсы имеют тенденцию быть изменчивыми, поля перемещаются и добавляются, форматы представления меняются. Автоматизировать это тестирование действительно сложно, поддерживать эти тесты еще сложнее. Иногда нам просто нужно стиснуть зубы и провести регрессионное тестирование вручную.   -  person djna    schedule 10.08.2009
comment
Всегда есть много тестов пользовательского интерфейса только с его дизайном, особенно с html / css, если вы проверяете несколько браузеров, которые добавляют к нему несколько проверок. Единственный раз, когда я когда-либо писал код для тестирования пользовательского интерфейса, — это использование сценариев AutoIt с устаревшим веб-приложением, которое было ужасно разработано с очень высокой степенью связи, что модульное тестирование было невозможно без нарушения работы приложения, поэтому я использовал Autoit для затирания данных в формы для меня вместо печатаю сам. Раньше я смеялся над другими разработчиками, которые предпочли бы тратить 6 минут за раз, вводя заявку на получение кредита, в то время как мне требовалось 2 минуты, после чего я мог уйти.   -  person Chris Marisic    schedule 10.08.2009

Ответы (2)


arrow_upward
4
arrow_downward

Но что, если кто-то (надеюсь, дизайнер) захочет изменить Button на MenuItem? Ваш тест сломается, и вам придется его починить. Одним из основных преимуществ MVVM является то, что дизайнеры могут свободно упорядочивать и изменять интерфейс так, как им нравится, не требуя слишком много общения с разработчиками. Написание модульных тестов для пользовательского интерфейса сводит на нет это благо.

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

Что касается того, как вы на самом деле тестируете представление в «изоляции». . . Я думаю, что самым простым способом было бы использовать модели просмотра с внедренными фиктивными сервисами. Ваши модели представления могут использовать локатор сервисов для захвата зависимых сервисов, поэтому ваши модульные тесты могут внедрять фиктивные сервисы. Затем вы можете использовать комбинацию ссылок на именованные элементы, визуального обхода дерева и API-интерфейсов автоматизации пользовательского интерфейса WPF, чтобы утверждать, что различные визуальные элементы имеют свойства, установленные должным образом.

person Kent Boogaart    schedule 10.08.2009

arrow_upward
0
arrow_downward

Я думаю, что есть что-то от Telerik (Art of test), которое может помочь автоматизировать необработанный пользовательский интерфейс. http://www.artoftest.com/products/webaii.aspx Хотя сейчас я посмотрели, что это Silverlight, а не WPF. Надеюсь, это по крайней мере хорошая отправная точка.

person Robin Vessey    schedule 10.08.2009
comment
Это выглядит хорошо, но это не отвечает на мой вопрос. Я специально ищу способ тестирования таких вещей, как привязки, команды и т. д. Простого запуска пользовательского интерфейса и проверки конечных результатов недостаточно, поскольку я не заинтересован в тестировании виртуальной машины или модели, а только самих представлений. Виртуальная машина или модель могут измениться в будущем, но мне не нужно также менять тесты просмотра. - person HAdes; 10.08.2009
comment
Да, достаточно честно, это хороший вопрос, я как бы удобно игнорировал этот момент до сих пор. ВНИМАНИЕ: в зависимости от объема работы, которую вы хотите выполнить, вы можете написать синтаксический анализатор/валидатор, чтобы убедиться, что все в модели повторно задано в представлении. Возможно, это не совсем то, что вы ищете, но это будет хорошей проверкой. - person Robin Vessey; 10.08.2009