Закодированный тест пользовательского интерфейса для изолированного тестирования компонентов пользовательского интерфейса

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

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

Мы попытались протестировать, запустив диалог как часть теста initialize (), но он не может найти элементы управления ... но тот же тест работает нормально, если я запускаю диалог отдельно.

Кто-нибудь пробовал это или посоветовал заставить это работать?


c# coded-ui-tests gui-test-framework
person user2786691    schedule 17.09.2013    source источник
comment
Похоже, что вы пытаетесь достичь модульного тестирования через графический интерфейс, и это не то, что представляет собой среда Coded UI Test.   -  person Omri Btian    schedule 17.09.2013

Ответы (3)


arrow_upward
2
arrow_downward

Coded UI Framework - очень мощный фреймворк, но у него много (я имею в виду МНОГО) проблем.

Я бы не рекомендовал делать то, что вы пытаетесь сделать.

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

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

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

Надеюсь это поможет.

person Omri Btian    schedule 17.09.2013

arrow_upward
1
arrow_downward

Кодированный пользовательский интерфейс предназначен для проверки работоспособности приложений (а также веб-страниц). Закодированный пользовательский интерфейс не предназначен для тестирования фрагментов пользовательского интерфейса отдельно от их приложения. Однако можно было бы создать приложение тестовой оснастки, содержащее один или несколько компонентов пользовательского интерфейса, позволяющих тестировать их изолированно от реального приложения.

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

person AdrianHHH    schedule 17.09.2013

arrow_upward
0
arrow_downward

Я думаю, что то, что вы пытаетесь сделать, жизнеспособно, но ТОЛЬКО для ваших собственных элементов управления. Думаю, вам следует заняться этим в таком порядке.

  1. Второй экземпляр VS для захвата того, что он на самом деле видит в вашем элементе управления, когда ваш тест порождает ваш элемент управления.
  2. Обновите критерии поиска, например имя процесса, заголовок окна
  3. Потенциально добавьте свойства в ваш TestInitialize spawner, чтобы он создавал ваш элемент управления с полезными идентификаторами, именами или заголовками. (не уверен, в каком технологическом стеке находится ваш контроль)
  4. Снова запустить тесты
person Michael Rieger    schedule 30.01.2018