Как правильно подходить к тестированию приложения WPF с использованием CodedUITest? - PullRequest
Новая
       20

Как правильно подходить к тестированию приложения WPF с использованием CodedUITest?

0 голосов
/ 13 мая 2011

Имеет приложение WPF со сложным пользовательским интерфейсом и хочет написать для него сценарии CodedUITest. Поскольку я новичок в этом, мне нужно правильное руководство / подход для написания сценария CodedUITest. Невозможно сделать все, используя Record & Play, потому что у нас есть некоторый пользовательский элемент управления, существующий в пользовательском интерфейсе, который можно изменить в любое время.

Я хочу сделать это, используя код C #. проблемы, возникающие при получении конкретной записи из пользовательской сетки и идентификации элемента управления с помощью кода C #.

  • Какие свойства должны быть у меня для контроля для легкой идентификации в CodedUITest?
  • Обязательно ли указывать AutomationId для всех элементов управления?
  • Что нужно сделать для динамических элементов управления, таких как Treeview и grid?
  • Как определить тип окна перетаскивания?

1 Ответ

1 голос
/ 24 мая 2011

Теоретическая сторона:

Кодовые тесты пользовательского интерфейса предназначены для проведения регрессионных тестов пользовательского интерфейса. Учитывая определенные данные, ваш пользовательский интерфейс должен реагировать определенным образом . Идея этого короля тестов заключается в том, что при одних и тех же данных пользовательский интерфейс продолжает вести себя одинаково. Другими словами: если для определенного набора данных ваш пользовательский интерфейс изменит то, как реагирует (основываясь на записях), тест должен сломаться .

Практический факт:

Кодированные тесты пользовательского интерфейса являются основой тестирования, а записи генерируют код. Вы можете увидеть этот код, и ИМХО, вы должны увидеть, как это работает. Если вам нужен более универсальный кодированный пользовательский интерфейс, вы можете добиться этого, изменив сгенерированный код. На самом деле я STRONGLY рекомендую разделить сгенерированные классы и методы и выполнить некоторые кланы.

Код генерирует своего рода карту пользовательского интерфейса (класс со свойствами, ссылающимися на объекты пользовательского интерфейса, используемые тестом). Вы можете настроить эту карту вручную, добавив или удалив свойства (в конце концов, это просто код), и создайте свою более сложную карту пользовательского интерфейса, фактически с усилием вы даже можете заставить карты «наследовать» от других карт (подробнее a la Главная страница ASP.Net).

В WPF вы можете проверить, существует ли элемент управления, его стиль пользовательского интерфейса, его содержимое и его дочерние элементы (если есть). Для объекта AutomationID является обязательным только в элементах управления, которые необходимо проверить. На D & D ... Понятия не имею. Я никогда не делал тесты пользовательского интерфейса для D & D.

...