Всем привет.
Есть вопрос на засыпку (когда-то, в далеком 2011 году, он тут уже звучал):
Автоматизация под Mac OS: как? что лучше использовать (всякие сикули и пропрочая картинко-кликалки не интересуют )? поделитесь опытом, если не трудно, не жалко и такой имеется.
Кто-то уже использовал фичи в XCode для тестирования UI десктопного приложения?
Зачем это нужно: портируется десктопный qt-проект с винды на Mac OS. В винде все четко работает с помощью MS UI Automation, поэтому хотелось бы сделать что-то похожее и под Mac OS, и, возможно, в будущем на линуксе.
Посмотрите на Linux Desktop Testing Project - Wikipedia
Из всех названных вами ОС он поддерживает все, плюс есть поддержка QT с версии 4.
Просмотрел их код на гитхабе, и вродебы они используют сигналы для доступа к элементам, так что кнопки нажимаются не по распознаванию образов (как в Сикули) а через ядро, что радует.
Да что вы говорите? У меня несколько сотен полноценных GUI тестов на QT. Как раз полноценных вы только на них и напишите, ибо доступ ко всем внутренностям вы кроме как изнутри самого QT практически никак не получите.
Я подразумеваю под доступом к внутренним функциям. Если проект больше окна с двумя кнопками, то как вы подготавливаете окружение? Как вы мокаете данные? Конечно все это можно сделать с 30 костылями, но если есть доступ к паблик функциям самого приложения, то зачем крутить велосипеды?
При тестировании с++ приложений black box может быть применимо только в случае, если у вас нет достаточных ресурсов для того чтобы нанять кого-то больше чем просто кликателя кнопочек, да и даже в таком случае дешевле будет настроить любой monkey testing tool. Как вы будете в блэк боксе разбираться почему оно падает? Как вы вообще нормально адекватно блэк боксом протестируете реальное приложение, в котором, повторюсь, есть больше пары экранов и трех кнопок?
Простейший пример, который можно приводить бесконечно - в приложении есть логин. На кнопке навешан сигнал вызова функции, сигнал сломали, функция работает, но дальше ничего не проходит или если у вас проблема с внешним логин сервисом? Что выяснит black box? Что все 100% тестов упали. Не работает ли 100% функционала приложения? Неизвестно. Почему? Потому что в ините вашего каждого теста мануальные шаги на вход в приложение. Что сделает тест, который сумеет залогиниться востальных тестах через вызов внутренней функции или через ее мок? Ответ - протестировать все внутри, отрапортовав о том что падает логин + результат всех внутренних тестов.
Какая будет стабильность ваших тестов, когда их будет несколько сотен? Никакой, вы только и будете заниматься тем, что чинить их и перезапускать каждый раз.
Black box вообще никак себя не оправдывает в реальных проектах с автотестами. Посмотрите еще старинное видео @asolntsev, где он рассказывает про мок сторонних сервисов, идея простая и гениальная, но к сожалению практически никогда не воплощаемая в реальность.
А такую встроенную тулзу как applescript не пробовал?
У нее очень много возможностей бегать по UI элементам приложения. Эта тулза интегрирована в систему, из нее можно вызывать шеловские команды. А разобраться с доступом к UI элементам приложения поможет такая тулза как UI Browser.
testomat.io управление авто тестами
Как он работает?
