среда, 6 апреля 2011 г.

UIAutomation. Начинаем.

Так, обзор пожеланий к тулам сделали, альтернативы посмотрели, даже про аджайл поговорили. Пора бы и честь знать начать бы и UIAutomation'ом пользоваться. Я планирую сейчас вкратце пробежаться по тому, как можно использовать UIAutomation "влоб" - как это задумал Apple. Так его использовать стоит далеко не всегда, но надо же с чего-то начинать.

Для начала неплохо бы этот инструмент иметь. Чтобы у вас завелся этот зверь, прийдется поставить XCode (среда разработки) с iOS SDK не ниже 4.0 - именно там он впервые появился. Последнюю версию можно взять тут, причем совершенно бесплатно, правда прийдется зарегистрироваться. Да, кстати, у Apple довольно интересная политика: инструменты они дают бесплатно, можете пользоваться, девелопить, тестить - на симуляторе. А вот чтобы собрать билд именно для девайса, - нужны сертификаты, и это уже за деньги. Впрочем, все это есть у них на сайте.

Итак, скачали, установили. Давайте пользоваться: запускаем Instruments, причем именно Instruments, а не UIAutomation. Просто Apple дает сразу кучу тулов, объединенных, скажем так, в один пакет, и UIAutomation - один из них. В общем, не суть, - возвращаемся к запуску. Если вы ничего не меняли в путях установки, то лежать эти самые Instruments будут по адресу /Developer/Applications/Instruments.app. Нашли? Запускаем, ждем... Открыться должно вот такое:


Выбираем категорию - в данном случае iOS Simulator, т.к. я хоть и работаю под девайсом, но показывать буду именно на симуляторе. В принципе, не суть важно, что вы выберете, различий все равно в результате не будет - под что автоматизировать, вы всегда можете перевыбрать.  Теперь кликаем шаблон Automation'a и получаем желаемый инструмент:

Это был стандартный шаблон, соответственно у вас в нем будут все (а их не так и много) настройки по умолчанию, а в моем случае, - уже те, которые были при последнем использовании. В частности у меня уже установлена папка, в которую будут складываться результаты.

Теперь нам нужно указать, что же именно мы будем тестить. Для этого нажимаем кнопку Choose Target и указываем сначала девайс. Мы будем запускать тесты на симуляторе, следовательно в качестве девайса выбираем свой компьютер:
Вариант "iPhone 12 (v4.2.1)" здесь присутствует потому, что у меня к компьютеру шнурком подключен айфон с iOS 4.2.1.

После выбора устройства идем в пункт меню Choose Target, который находится чуть ниже, и указываем приложение *.app, которое мы предварительно собрали для симулятора (если не собрали - собираем, так как очень сложно тестировать то, чего нет :), причем собираем исключительно в Debug режиме, иначе UIAutomation не сможет с ним работать. Собственно говоря, я для этого поста собрал самое простое приложение, оно абсолютно пустое, но для демонстрации вполне пригодно:

Если бы мы хотели тестировать приложение на iPhone, то принцип выбора приложения был бы примерно тем же: мы выбрали бы в качестве целевого устройства требуемый iPhone и указали бы приложение, на нем установленное. Да, кстати, тут есть несколько важных моментов: во-первых девайс должен непременно быть подключен шнурком к тому компьютеру, на котором будет запускаться UIAutomation, во-вторых, приложение уже должно быть установлено на девайс (UIAutomation умеет сходу ставить и запускать приложения только под симулятором, под девайсом - только запускать уже установленные), и в третьих, еще раз повторю, что тестировать можно только приложение, собранное под Debug. 

Так, приложение мы выбрали, осталось указать папку для хранения результатов тестовых прогонов (это делается в разделе Logging, см. слева внизу) и файл с тестовыми скриптами. На самом деле UIAutomation умеет запускать скрипты только из одного файла за раз. Как это обойти я покажу позже, а пока давайте просто создадим наш первый скрипт:
//Пишем в лог сообщение о начате тестинга 
UIALogger.logMessage("The test startet."); 
//получаем и пишем в лог дерево всех UI элементов приложения 
UIATarget.localTarget().frontMostApp().logElementTree(); 
//Собственно, все :) 
UIALogger.logMessage("The test finished.");
В этом куске кода можно подозревать чуть не любой язык, но это JavaScript. Здесь хочется особо отметить строку, в которой мы выводим в лог дерево объектов приложения, т.к. это главный способ получения информации о контролах в UIAutomation.

В общем, сохраняем этот код под любым именем и указываем его в окне UIAutomation в разделе Script. Теперь можно запускать выполнение. Для этого либо идем в меню и кликаем на пункте Run, или нажимаем на круглую кнопку с надписью, как это ни странно, Record (Apple, что с них взять). Вот так выглядит окно UIAutomation после выполнения нашего теста:
Да, чуть не забыл, останавливать выполнение тестов надо тоже вручную, иначе этот чудный инструмент будет думать, что он еще тестит :) Эта проблема тоже обходится, хоть и не сильно красиво. Про это будет, надеюсь, отдельный пост.

В принципе, это все, осталось только сказать, что в результате прогона мы получаем файл с результатами Automation Results.plist, который лежит в папке Run 1 (или Run 2, если вы запустите тест второй раз), которая в свою очередь лежит там, где вы сказали хранить результаты. Я не нашел способа указывать этому файлу другое имя, если найдете - поделитесь.
По сути, это xml-файл, так что обрабатывать его можно вполне цивилизованно, а можно и не обрабатывать, решать вам :)

На этом я пост закончу, дальше будут еще посты про этот инструмент и в этих постах я буду рассказывать про проблемы с UIAutomation и про пути их решения более подробно.

9 комментариев:

  1. > во-первых девайс должен непременно быть подключен шнурком к тому компьютеру, на котором будет запускаться UIAutomation

    необязательно, в документации написано что можно по воздуху цеплять, если мак и девайс находятся в одной локалке и точка сконфигурирована с поддержкой бонжур:
    http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/SpecifyingtheProcesstoTrace/SpecifyingtheProcesstoTrace.html#//apple_ref/doc/uid/TP40004652-CH12-SW16

    >причем собираем исключительно в Debug режиме, иначе UIAutomation не сможет с ним работать

    сможет, опять же в документации написано что тул позволяет тестировать собранное для аппстора приложение, кроме того сама не раз запускалась на релизной версии.
    http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Built-InInstruments/Built-InInstruments.html#//apple_ref/doc/uid/TP40004652-CH6-SW76
    (Your test script must be a valid executable JavaScript file accessible to the instrument on the host computer. It runs outside your application, so the tested version of your application can be the same version that you submit to the iTunes App store.)

    А вот если галочка Accessibility в интерфейс билдере не стоит, то тогда конечно до элемента никак не достучишся

    Вообще статья хорошая, автору спасибо и респектище, еще ниразу не находила рускоязычных постов вменяемо описывающих работу данного тула :)

    ОтветитьУдалить
  2. Спасибо за коммент, тем более, что по делу :) Немножко отпишусь.

    Почему шнурок? Просто не раз наблюдалась проблема коннекта: Instruments просто "теряли" девайс, а так как мы используем связку UIAutomation с CIT-билдами, то для нас важно, чтобы таких проблем было поменьше. Так что я просто поделился своими граблями, вернее, их обходом :)

    По поводу тестового прогона на билде собранном по Release - это я попозжее перепроверю, пока же могу точно сказать, что на AdHoc билде не пойдет, - возвращает ошибку таргета. Кстати говоря, приведенный фрагмент доки говорит не столько о том, что вы можете запускать тесты на релизном билде, сколько о том, что в приложение не будет внесено изменений, соответственно, наличие тестов не повлияет на результат контроля этого приложени, который проводят на апсторе.

    Наконец о галочке в интерфейс билдере. Если ее выключить, соответствующий элемент действительно не будет виден. Хотя вопрос с видимостью гораздо шире и интереснее, и одними галочками вы не обойдетесь. Даст Бог, об этом я еще напишу позже :)

    ОтветитьУдалить
  3. Со всем согласна :) Насчет потери коннекта - ниразу не ловила такого бага, собственно на девайсе мало запускалась, поэтому не пришлось, но за дельный совет Спасибо :)

    ОтветитьУдалить
  4. Даешь новый пост с целым инвентарём граблей!

    ОтветитьУдалить
  5. Привет. Может вы сталкивались со следующем соббщением "Automation is not available for this type of application?"

    ОтветитьУдалить
  6. Привета :) Сталкивался, я получал такое сообщение тогда, когда пытался использоваться недебажную сборку, помнится, я об этом даже писал в этом посте. Второй причиной может быть выключенный Accessibility на симуляторе. Он включается в конфиге для каждой версии iOS, которая есть на симуляторе.

    ОтветитьУдалить
  7. Спасибо за полезный пост!

    ОтветитьУдалить
  8. Привет! А UI Automation при прогоне записанного кейса сравнивает экраны по скриншотам? Просто у Monkey Talk такой принцип работы вроде как.

    ОтветитьУдалить
  9. Привет, вот сейчас на скажу уже, я как-то в другую, менее техническую степь убежал и давно не работал с UIA, многое успело подзабыться. На тот момент, когда я им плотно пользовался, возможности сравнивать скриншоты не было в принципе.

    Кстати, по поводу манки-тока, я не уверен, что он работает именно на сравнении скринов: флоу там задавался на уровне отдельный контролов с описанием необходимых ивентов к ним. То, что вы написали, больше к Cucumber относилось, насколько я помню :)

    ОтветитьУдалить