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

Question

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

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

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

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

Answer 1

Coded UI Framework - очень мощная структура, но имеет множество (и я имею в виду LOTS) проблем.

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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