Тестирование тяжелого графического приложения WPF

На мой взгляд, одной из основных сильных сторон WPF является то, что он НЕ требует тестирования конкретного пользовательского интерфейса. Использование подхода M-V-VM позволит вам извлечь логику из области пользовательского интерфейса / беспорядочного графического интерфейса пользователя. Наличие тестируемой модели ViewModel (особенно если вы пишете новые диалоги!) Позволяет вам писать модульные тесты, имитирующие щелчки в вашем графическом интерфейсе.

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

Как говорит Джимми Лайк, большая часть вашего тестирования должна быть сосредоточена на ViewModel. Это состоит из написания модульных тестов для ViewModel - в основном отправки команд, настройки и получения свойств.

Как только это будет сделано, 95% вашего тестирования прекратится. Если вы хотите сделать еще один шаг и протестировать представление, выходящее за рамки ручного «пошагового» тестирования, которое вы все равно выполняли бы, существует ряд простых «проверок работоспособности», которые вы можете легко автоматизировать, чтобы убедиться, что вы случайно не удалили важный TextBox или сделать визуальный индикатор невидимым.

Каждый из следующих методов может быть автоматизирован с помощью некоторого простого кода автоматизации, который использует подход «дробовика» путем слепого запуска визуального дерева и ничего не предполагая о фактической структуре пользовательского интерфейса.

• Чтобы убедиться, что все данные ViewModel связаны, найдите все Visuals и Freezables (используя визуальное дерево) и проверьте каждое связанное свойство на предмет пути привязки его BindingExpression.

• Чтобы убедиться, что все данные ViewModel каким-то образом отображаются, измените данные ViewModel с помощью сценария и после каждого изменения используйте RenderTargetBitmap для захвата пользовательского интерфейса и сравнения его с данными перед изменением, чтобы убедиться, что пользовательский интерфейс изменился.

• Чтобы убедиться, что значения свойств обновляются правильно, найдите все Visuals и Freezables, сканируйте и запишите все связанные свойства на них, затем измените ViewModel, выполните повторное сканирование и выполните поиск ожидаемого изменения любого свойства данного типа. . (Чтобы перепроверить, вы можете затем использовать технику сравнения растровых изображений на конкретном затронутом визуале.)

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

• Чтобы убедиться, что свойство ViewModel действительно доступно для редактирования пользователем, измените содержимое или выделение каждого видимого TextBox, ComboBox, ListBox, чтобы увидеть, влияет ли какой-либо из них на свойство.

• Чтобы получить возможность проверить любые изменения, влияющие на пользовательский интерфейс, храните базу данных, содержащую моментальные снимки растровых изображений каждого представления в различных состояниях ViewModel в наборе окон разных размеров. При создании новой версии приложения запустите ту же систему моментальных снимков и сравните с предыдущими растровыми изображениями. Если что-то вообще изменилось, сгенерируйте вручную задачу для персонала QA, чтобы визуально сравнить старые и новые растровые изображения, чтобы увидеть, изменилось ли что-нибудь важное.

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

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

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

У вас не так много вариантов, но:

1. Рефакторинг кода по мере продвижения. Это может быть небольшое извлечение методов, чтобы вы могли выполнить модульное тестирование или перейти на подходящую модель.
2. Используйте один или несколько из множества инструментов тестирования графического интерфейса Windows . Обратите внимание: если вы планируете много изменений макета и / или управления, отложите это как можно дольше. Инструменты в этой статье будут использовать абсолютное позиционирование действий, связанное управление (иногда с помощью внутренних идентификаторов) или их комбинацию. Поскольку их обычно нужно обучать без использования кода (предназначенного для тестировщиков QC, а не для программистов), ваши тесты перестанут выполняться после изменения.
3. Инвестируйте в человеческих тестировщиков. Хотя это не лучший выбор, он улучшает качество завершения и заставляет руководство больше думать о затратах на рефакторинг приложения.

Чтобы протестировать приложения WPF, мы добились успеха в нескольких вещах:

1. PowerShell
2. TestPlant

и, возможно, это будут новые функции VSTS 2010 , хотя мы не пробовали их