Comments 10
Интересная статья! Возьму на заметку.
Раз уж пошла такая пьянка
то я могу Вам предложить ознакомиться со своей наработкой. Я, кстати, о ней писал на хабре и скоро будет еще материал. Она базируется на Page Object'х, WebDriver API и задумывется как нечто кросс-платформенное и позволяющее работать как с браузерами, так и с мобильными приложениями:
— habrahabr.ru/post/242947/
— habrahabr.ru/post/244329/
Ссылка на github есть прямо в статьях.
Раз уж пошла такая пьянка
Наверняка многим из читающих эту статью есть чем поделиться в области автоматизации тестирования. Предлагаю делиться наработками в этой области в комментариях.
то я могу Вам предложить ознакомиться со своей наработкой. Я, кстати, о ней писал на хабре и скоро будет еще материал. Она базируется на Page Object'х, WebDriver API и задумывется как нечто кросс-платформенное и позволяющее работать как с браузерами, так и с мобильными приложениями:
— habrahabr.ru/post/242947/
— habrahabr.ru/post/244329/
Ссылка на github есть прямо в статьях.
Мы используем стандартный Continuous Integration
Отлияная статья.
Я когда использовал с IOs там было очень токое место по установки приложения на живой девайс. Вы это решили или эмулятор используете?
Я когда использовал с IOs там было очень токое место по установки приложения на живой девайс. Вы это решили или эмулятор используете?
Мы используем и iOS-симулятор, и «живые» девайсы в зависимости от конкретных задач. Проблему установки приложений на девайс позволяет решить утилита fruitstrap github.com/igorsokolov/fruitstrap. Утилита запускается из командной строки и позволяет обойтись без использования XCode.
Хорошая статья, хорошая система. Но не могли бы вы немного раскрыть обоснование выбора именно таких инструментов? Очевидно, что на внедрение потребовался не день и не два, это был долгий и трудоемкий процесс. Одно только написание вспомогательных скриптов чего стоит. У меня сразу возник вопрос, а нет ли чего-то подобного, но с более низкими требованиями для запуска? Как минимум, с уже готовым набором скриптов, пусть и не покрывающим 100% необходимого?
Есть интерес (и уже даже необходимость назрела) внедрить такую штуку у нас на производстве, но от беглой оценки масштабов трудозатрат становится немного не по себе. Или я преувеличиваю?
Есть интерес (и уже даже необходимость назрела) внедрить такую штуку у нас на производстве, но от беглой оценки масштабов трудозатрат становится немного не по себе. Или я преувеличиваю?
Как говорится, глаза боятся, а руки делают))) Альтернативным вариантом является запуск автотестов в рамках Continuous Integration сервера, но тут можно столкнуться с проблемой, когда Calabash не может стартовать тест с ошибкой execution expired или Errno::ECONNREFUSED. Причина этого в том, что контекст, в котором запущен ssh-сервер на mac os x не поддерживает запуск GUI-приложений. Возможным решением является запуск через JNLP. Мы же пошли другим путем и изобрели свой удобный, трехколесный велосипед)) Базовых знаний bash вполне достаточно, чтобы автоматизировать процессы запуска тестов.
Сам занимался этим полтора года на прошлой работе. У Calabash большие перспективы. Основное преимущество по-сравнению с другими фреймворками — очень гибкий язык запросов.
Calabash пусть и не кросс-платформенный на все 100%, но уж мульти-платформенный это точно, я имею ввиду что есть еще Calabash for Android. API у них, к сожалению не совпадают полностью и даже есть определенные различия в синтаксисе запросов, но это вполне решаемо с помощью одного уровня абстракции в коде или даже пул реквестов.
Меня вот немного удивило использование Automator-а, почти все можно сделать с помощью shell/ruby скриптов и ios-sim. Например calabash-ios sim reset сбрасывает настройки симулятора, с помощью DEVICE_TARGET переменной окружения можно ресетить только один какой-то симулятор. Ну естественно эта команда использует Automator скрипт, во многом похожий на ваш.
К тому же разве все это не должно происходить как часть процесса Continuous Integration? Т.е. в данном примере как часть build pnan/job на TeamCity? Если будете масштабировать, добавлять новые билд боксы, получите децентрализованную систему где на каждой машине крутится свой автоматор. Именно для этого у TeamCity, также как и у Bamboo, Jenkins и других есть поддержка билд агентов. Но тогда все эти задачи (git, calabash.framework, xcodebuild, тесты и отчеты) должны выполняться как часть билда (build job или build plan, или что там у TeamCity). Один и тот же план может выполняться параллельно на нескольких агентах.
И если будете вдруг поддерживать Андроид, то тесты для андроида можно гонять на Linux машинах, где Automator-а нет.
Calabash пусть и не кросс-платформенный на все 100%, но уж мульти-платформенный это точно, я имею ввиду что есть еще Calabash for Android. API у них, к сожалению не совпадают полностью и даже есть определенные различия в синтаксисе запросов, но это вполне решаемо с помощью одного уровня абстракции в коде или даже пул реквестов.
Меня вот немного удивило использование Automator-а, почти все можно сделать с помощью shell/ruby скриптов и ios-sim. Например calabash-ios sim reset сбрасывает настройки симулятора, с помощью DEVICE_TARGET переменной окружения можно ресетить только один какой-то симулятор. Ну естественно эта команда использует Automator скрипт, во многом похожий на ваш.
К тому же разве все это не должно происходить как часть процесса Continuous Integration? Т.е. в данном примере как часть build pnan/job на TeamCity? Если будете масштабировать, добавлять новые билд боксы, получите децентрализованную систему где на каждой машине крутится свой автоматор. Именно для этого у TeamCity, также как и у Bamboo, Jenkins и других есть поддержка билд агентов. Но тогда все эти задачи (git, calabash.framework, xcodebuild, тесты и отчеты) должны выполняться как часть билда (build job или build plan, или что там у TeamCity). Один и тот же план может выполняться параллельно на нескольких агентах.
И если будете вдруг поддерживать Андроид, то тесты для андроида можно гонять на Linux машинах, где Automator-а нет.
Да, у Calabash есть команды для сброса симулятора (sim reset) и установки языка (sim locale), но, к сожалению, при переходе на XCode 6 и iOS Simulator 8 они перестали работать. С выходом новых версий Xcode и симулятора наблюдается активная деятельность со стороны разработчиков Calabash и возможно данные проблемы уже пофикшены.
То, что касается использования Automator… На самом деле большая часть функционала, необходимого для автоматизации реализована с использованием shell-скриптов. Но их вызовы оформлены как шаги Automator-скрипта. Фактически, Automator обеспечивает удобный запуск по расписанию (с помощью Календаря) и легкий доступ к возможностям Mac OS. Думаю, те же самые скрипты легко можно использовать и в build steps CI-сервера.
То, что касается использования Automator… На самом деле большая часть функционала, необходимого для автоматизации реализована с использованием shell-скриптов. Но их вызовы оформлены как шаги Automator-скрипта. Фактически, Automator обеспечивает удобный запуск по расписанию (с помощью Календаря) и легкий доступ к возможностям Mac OS. Думаю, те же самые скрипты легко можно использовать и в build steps CI-сервера.
Это не совсем минусы Calabash. Как я уже сказал, они точно также используют Automator скрипт для сброса симулятора. Т.е. раз их скрипт сломался, то нет гарантии что ваш не сломается точно также. Это на самом деле стандартные заморочки при обновлении Xcode или Mac OS X, всегда есть вероятность что где-то что-то сломается. Ну и даже если что-то сломается фикс рано или поздно найдется. Вот вы например нашли как пофиксить проблему с локалями, по идее ничего не мешает открыть пул реквест с этим фиксом чтобы он попал в следующий релиз Calabash :)
Да, shell скрипты хороши тем, что их легче использовать повторно. В вашем случае, если вдруг не станет хватать мощностей одной Mac OS машины, и вы добавите еще одну, тогда CI-сервер и агенты подойдут лучше. Но это всегда итеративный процесс, постоянные улучшения — норма.
Да, shell скрипты хороши тем, что их легче использовать повторно. В вашем случае, если вдруг не станет хватать мощностей одной Mac OS машины, и вы добавите еще одну, тогда CI-сервер и агенты подойдут лучше. Но это всегда итеративный процесс, постоянные улучшения — норма.
Sign up to leave a comment.
Автоматизация тестирования iOS-приложений с применением Calabash и Cucumber