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

Question

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

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

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

Answer 1

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

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

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

Кодовые тесты UI являются основой тестирования, и записи генерирует код. Вы можете видеть этот код, и IMHO вы должны увидеть, как это работает. Если вам нужен более универсальный кодированный пользовательский интерфейс, вы можете достичь этого, изменив сгенерированный код. Фактически я СИЛЬНО рекомендую разделить сгенерированные классы и методы и сделать несколько clanup.

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

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