Существует ли возможность работы с элементами devExpress в тестах coded UI? Инструменты для автоматизированного тестирования UI с поддержкой devExpress

Добрый день!
Руководством была поставлена задача автоматизации тестирования desktop приложения, написанного на delphi. Из инструментов на данный момент имеется Visual Studio 2013 и coded UI, его и использовала.
Однако, в ходе написания пробных тестов выяснилось, что в приложении присутствуют элементы интерфейса, созданные с использованием DevExpress. И через CUIT к ним достучаться не получается (например, элемент TcxGrid). На форуме поддержки DevExpress так же нашла ответы, что через CUIT с их элементами работать не получится.
В связи с этим вопрос, есть ли какая-то возможность достучаться до подобных элементов? Возможно не через запись рекордером, а вручную (подключить DevExpress к проекту, описать его контролы руками в карте UIMap.cs) по аналогии с тем, как это делает рекордер?

Возможно сможете подсказать какой-то инструмент, позволяющий работать с DevExpress? Желательно бесплатный, т.к. покупать testcomplete или ranorex компания не станет.
Пока пробовала ознакомится с pywinauto и SWAPY, словила кучу ошибок, судя по коментам на git, не поддерживается уже.

Возможно есть какие-то плагины для студии по работе с DevExpress, но я пока ничего не нагуглила…

Заранее спасибо за помощь!

Добрый день!
Для определения devExpress элементов Вам нужно установить компонент DevExpressCodedUIExtension

1 лайк

Добрый день!
Спасибо за совет. Это расширение действительно может частично решить проблему, но, к сожалению, в нашем ПО по большей части использованы компоненты, которые поддерживают только события мыши и клавиатуры.:frowning_face:

SWAPY действительно не поддерживается, но только потому, что pywinauto убежал вперёд и поддерживает в том числе и технологию MS UI Automation (как и Coded UI), а на замену SWAPY пока есть только инспектор py_inspect без генератора кода (впрочем, можно ожидать record-replay этой осенью-зимой). Конкретно до DevExpress у нас ещё руки не доходили. Скорее всего полный доступ к свойствам возможен только через managed DLL injection (пока только примерно знаю, как это делать; в опен сорсе глубокого использования не видел пока). Полагаю, платные инструменты именно этот подход и юзают (как минимум TestComplete и Squish).

По pywinauto есть видео-лекция: Десктопные GUI-тесты на Python. Лекция в Яндексе / Habr
и текстовая статья а ля туториал: Автоматизируем десктопный GUI на Python + pywinauto: как подружиться c MS UI Automation / Habr

Добрый день, Подскажите, pywinauto справиться с таким?

Тут есть несколько вариантов.

  1. Бага в самой реализации грида, из-за которой не обновляется accessibility инфа (если, скажем, Inspect.exe показывает старые данные, то это оно). В этом случае никто, кроме разработчиков грид контрола, не поможет.

  2. Не знаю, использует ли Winium кэширование для оптимизации запросов к приложению. Есть такая фича в MS UI Automation API (который и Winium, и pywinauto используют). Конкретно pywinauto по умолчанию не использует кэширование, так что должно работать (если это не случай №1, см. выше). К тому же, типичное использование pywinauto подразумевает повторный поиск элемента. Это не всегда супербыстро, зато всегда актуально. Если захочется быстрее, нужно будет освоить пару трюков вроде использования child_window(..., control_type="...").

  3. Если Winium таки использует кэширование, то может в нём же есть способ отключить его. :slight_smile: