Всем привет!
Меня зовут Сергей Дударев, я руководитель направления автоматизированных тестов в департаменте мобильной разработки «Лаборатории Касперского». В этой статье хочу рассказать, как я прошел путь от Appium до open-source-фреймворка Kaspresso, с чего начинал, какие делал для себя открытия, как разрушались мои стереотипы и какие по итогу были сделаны выводы.
5 марта в питерском офисе Одноклассников состоится ок.tech: QATOK #2 – митап, посвященный тестированию и всему что связано с обеспечением качества в ИТ-проектах. Нас ждет 3 технических доклада от представителей OK, Яндекса и VK, ребята расскажут про проблемы Espresso-автотестов Android в реальном мире, поделятся опытом использования Openapi-generator для написания автотестов на REST-API и покажут, как проводить оценку тестового покрытия API без снятия Сode Сoverage.
Работая над последним проектом, столкнулся с тестированием мобильного приложения, связанного на уровне бизнес-логики с различными сторонними сервисами. Тестирование этих сервисов не входило в мою задачу, однако проблемы с их API блокировали работу по самому приложению – тесты падали не из-за проблем внутри, а из-за неработоспособности API, даже не доходя до проверки нужной функциональности.
Традиционно для тестирования таких приложений используются стенды. Но они не всегда работают нормально, и это мешает работе. В качестве альтернативного решения я использовал моки. Об этом тернистом пути и хочу рассказать сегодня.
11 августа в нашем офисе прошел Avito Mobile Testing Meetup — митап, полностью посвященный тестированию приложений на платформах iOS и Android. Говорили о качестве мобильного приложения — как понять, что оно работает должным образом, о нативных UI-тестах в iOS — что тестировать и какие инструменты помогут их улучшить. Обсуждали, что лучше использовать в тестировании Android-приложений — Appium или Espresso, и в end-to-end тестах — можно ли их организовать в больших мобильных проектах, и не только.
Кроме того, коллеги из Яндекса рассказывали о своём инструменте тестирования производительности мобильных телефонов, а мы представили телеграм-бота Гошу, который присматривал за всеми из-за угла, провели целых две викторины и наградили участников, приехавших на митап из Волгограда и Воронежа. В общем, получился настоящий фестиваль мобильного тестирования.
Под катом делимся впечатлениями, фото, видео, презентациями со встречи и отзывами слушателей.
11 августа в офисе Авито пройдет первый митап, посвященный тестированию мобильных приложений на платформах iOS и Android. Поговорим о нативных UI-тестах в iOS — что тестировать и какие инструменты помогут их улучшить, end-to-end тестах — можно ли их организовать в больших мобильных проектах, качестве мобильного приложения — как понять, что оно работает должным образом, и выясним, что лучше использовать в тестировании Android-приложений — Appium или Espresso. Обо всем этом расскажут Артем Разинов (Авито), Павел Иванов (Альфа-Банк), Алексей Денисов (PTScientists) и Алексей Емелин (Яндекс). Под катом — тезисы выступлений докладчиков, ссылка на регистрацию и важная информация по трансляции митапа.
С праздниками, друзья! Если вы не против научиться на каникулах чему-то новому, прочитайте лекцию Кирилла Борисова — разработчика систем авторизации Яндекса. Кирилл объясняет, как построить процесс тестирования Android-приложений, знакомит с современными инструментами и спецификой их использования.
— Прежде чем двинуться вперед, давайте устроим небольшой соцопрос. Кто из вас знает, что такое тесты? Кто пишет тесты? А кто знает, зачем он пишет тесты? Читать полностью »
Автор этой лекции — Константин Заикин, руководитель группы разработки Яндекс.Браузера для Android в Санкт-Петербурге. Он рассказал об инструментах Android-разработчика и всей команды, а также о том, как справляться с legacy-кодом, публиковать большой проект вовремя и улучшать качество кода.
— Друзья, привет. Я очень рад, что вас так много сегодня пришло. Я приехал из Питера, в Яндексе работаю около шести лет. Успел засветиться в Картах, Такси, Метрике и Поиске. Уже два года я работаю над Яндекс.Браузером для Android.
В компании «Agoda» мы уделяем много внимания различным видам тестирования нашего кода. Это помогает нам гарантировать его стабильность и находить возможные проблемы продукта на раннем этапе.
В данный момент, тестирование пользовательского интерфейса на Android для нас является небольшим персональным филиалом ада. Google предоставляет нам Espresso вместе с несколькими расширениями, UI автоматор и так далее. И хоть инструменты отлично справляются c возложенной на них задачей, делают они это не очень красиво. Когда вам нужно протестировать кейс, отличающийся от простого клика по кнопке, ваш тестовый код превращается в месиво, сложно поддающееся чтению. Просто взгляните:
@Test
public void espressoTest() {
onView(allOf(allOf(withId(R.id.label_bf_hotelname),
isDescendantOfA(withId(R.id.custom_view_trip_review))),
isDescendantOfA(withId(R.id.contentView))))
.check(matches(withEffectiveVisibility(View.VISIBLE)));
}
Для меня этот код выглядит малочитаемым. Очень сложно поддерживать работу более чем 1000 UI тестов нашего Android приложения с подобным синтаксисом. Но Google объявила официальную поддержду языка Kotlin как языка для Android разработки на конференции Google I/O 2017. Тогда то мы и подумали: «А ведь мы можем попробовать мигрировать наши тесты на Kotlin!»
Но просто трансляция кода из Java в Kotlin не решает нашу проблему с читаемостью тестов, так как мы все еще зависим от Espresso. К счастью, Kotlin предоставляет нам множество инструментов для создания DSL. Имея это ввиду, мы представили как наши UI тесты должны выглядеть на Kotlin'е. Мы хотели, чтобы тест выше выглядел вот так:
@Test
fun espressoTest() {
screen { hotelName { isVisible() } }
}
Выглядит здорово, вы так не считаете? Гораздо более читаемый и с легкостью понимаемый код, чем при использовании Espresso. И в большинстве ситуаций более компактный. Удалось ли нам добиться такого синтаксиса? Еще как!
Читать полностью »
Я помню то замечательное время, когда сборка релизной версии мобильного приложения сводилась к тому, что нужно было выставить debug = false и запустить экспорт apk-файла. Проходит 2 минуты, пока пыхтит IDE, и все готово. Все усилия сосредотачивались на необходимости указать данные сертификата подписи. Это было совсем недавно. Cейчас процесс сборки того самого приложения разросся настолько, что, если мне, вдруг, потребуется выполнить все операции самостоятельно, и даже если я все вспомню и проделаю безошибочно (во что я не верю), то это займет не час, который сегодня кажется непозволительно долгим, а, скорее всего, сутки, после чего терапевт обязан будет прописать мне больничный по усталости недели на две.
Итак, процесс сборки мобильного приложения. Попробую рассказать, из чего он у нас состоит — не потому, что в последнее время стало модным катать посты о CI той или иной мобильной команды (с покером, русалками и прочими обязательными атрибутами), а потому, что это отличный опыт, который я получил, работая над Почтой Mail.Ru для Android, и потому, что этой возможности, вероятнее всего, не было бы, работай я в другой команде, над другим проектом или в другой компании.
Читать полностью »
Относительно не так давно появилась замечательная библиотека Espresso для тестирования UI Android приложений. Её преимущества над аналогами обозревались не один раз. Если вкратце, то они заключаются в том, что это разработка Google для собственной ОС (ранее они сами использовали Robotium), а так же в лаконичности синтаксиса и скорости работы. Итак, мы решили идти в ногу со временем и использовать Espresso. Но нам мало тех плюсов, что уже есть, мы хотим BDD (http://en.wikipedia.org/wiki/Behavior-driven_development), мы хотим скриншотов и отчетов в json и html, мы хотим запускать это все на CI, в конце концов! Но обо всем по порядку. Я расскажу как подружить Cucumber (http://habrahabr.ru/post/62958/) и Espresso (http://habrahabr.ru/post/212425/) на небольшом примере. Всех, кто устал от Appium, кто хочет уйти от Robotium и тех, кому небезразлично тестирование Android, прошу под кат.
Читать полностью »