Опыт работы с UI Automation и WPF [закрыто]

Question

Мы разрабатываем довольно большое приложение на основе WPF и хотели бы включить в наш набор тестов некоторое автоматическое тестирование пользовательского интерфейса (которое уже содержит несколько модульных тестов).

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

Итак, кто-нибудь имеет реальный опыт использования UI Automation Framework в своем наборе тестов? Каковы предостережения и ошибки? Любые лучшие практики при написании тестовых сценариев можно "записать и воспроизвести"; в формате сценариев, насколько вы должны облегчить тестирование из приложения, как вы включили его в автоматическую сборку? Должны ли мы смотреть в другом направлении, чем UI Automation Framework?

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

Answer 1

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

Мы пытались настроить их так, чтобы они выглядели как модульные тесты, т. е. [TestFixture] [Test] и т. д. тогда мы смогли запустить их через nunit одновременно с юнит-тестами.

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

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

Answer 2

Я занимаюсь автоматизацией пользовательского интерфейса приложения WPF на работе. Я использую White и IronRuby, и это прекрасно работает. Я написал, как я это сделал здесь: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

Сначала мы пошли с белым, а затем отошли от него. Он пытается быть обобщенным и абстрактным для Win32 API, Winforms, приложений Java и API автоматизации пользовательского интерфейса MS. API автоматизации пользовательского интерфейса MS также пытается быть обобщенным и абстрактным в отношении win32 api, winforms и WPF, поэтому вы в конечном итоге получаете «наименьший общий знаменатель наименьшего общего знаменателя»; сценарий.

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

Мы закончили тем, что выбрали доморощенную платформу; Мы напрямую используем инфраструктуру MS UIAutomation, но у нас есть методы расширения и вспомогательные классы для работы со сценариями, к которым она не относится. (В первую очередь ввод с клавиатуры и мыши).

Примечание: наши тестовые скрипты и доморощенные фреймворки используют IronRuby. Способность Ruby добавлять методы к существующим классам и его гибкий синтаксис (в сочетании с method_missing) превосходны для такого рода вещей.