Как на авито сделать чтобы мне писали сообщения: Как писать и запрещать личные сообщения на Авито?

Загрузка…

Бесплатные купоны

Kaspresso: платформа автотестирования, которую вы так долго ждали. Часть I | Евгений Мацюк

Мир меняется с невероятной скоростью. Самый ценный и важный ресурс сейчас – это Время. Успех принадлежит тем, кто умеет лучше управлять временем.

Что означает время в разработке продукта? Вы должны выпустить свои функции как можно скорее, то есть улучшить показатель времени выхода на рынок. Я уверен, что вы слышали этот термин, но позвольте мне напомнить вам, что это такое. Время выхода на рынок — это время, в течение которого команда разрабатывает функцию из идеи и доставляет ее конечным пользователям.

Как сократить время выхода на рынок? Есть много разных вариантов, и один из них — сократить время, затрачиваемое на ручные регресс-тесты. Итак, как сократить время до релиза? Да, просто автоматизируйте тестирование.

Так просто сказать «Автоматическое тестирование». Но как начать?
Первое препятствие, с которым вы столкнетесь, это выбор инструмента.

Вы видите много разных фреймворков и инструментов для автотестов. В настоящее время основная битва идет между Appium и Espresso.
Сравнение таких инструментов посвящено большому количеству докладов и статей, которые вы можете прочитать в свободное время. Короче говоря, Espresso лучше из-за следующих особенностей:

• Это родной инструмент. Гугл рекомендует.
• Эспрессо стабильнее и быстрее, чем Appium. Это утверждение обосновано отсутствием промежуточных слоев в эспрессо.
• Эспрессо удобнее для разработчиков. Разработчик может писать и отлаживать UI-тесты в Android Studio в одном проекте.

К сожалению, эспрессо не так совершенен и не удовлетворяет всем нашим потребностям. Как так?

Вы будете похожи на этого человека, пытаясь прочитать такой код.

Что ты видишь? API, подробно описывающий простую функцию. Но эта функция содержит только три действия: поиск кнопки, проверка видимости кнопки и нажатие на кнопку. Вы можете понять это из этого кода? Конечно, но тебе нужно время.

Ненадежность

Следующая неприятная черта любого UI-тестового фреймворка, не только Espresso, — это ненадежность.
Ваш тест может пройти десять раз подряд. Но с одиннадцатой попытки тест срывается. Причина и момент, когда тест не проходит, могут быть абсолютно неопределенными. А на двенадцатой попытке тест снова зеленый. Все это похоже на черную магию.

Ведение журнала

Красивые журналы и сообщения об ошибках, предоставленные Espresso. Это распространенное сообщение об ошибке. Что произошло? Фу.
Кроме того, вы не можете наблюдать, что делает ваш тест во время выполнения, потому что Espresso не выводит никакой полезной информации.

Архитектура тестов

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

Espresso не содержит инструментов для взаимодействия с ОС Android. Эспрессо бесполезен, если вы хотите передать некоторые файлы на устройство или имитировать телефонный звонок. Также ADB невозможен в Эспрессо-тестах. Но Appium-тесты могут его использовать.

Сценарии обновления

Архитектура эспрессо-тестов не позволяет автоматизировать сценарии обновления (при обновлении приложения). Вы знаете, что любое прерывание процесса приложения не проходит тест. Но во время обновления приложения мы останавливаем и перезапускаем процесс приложения.
Вот почему поведение ОС Android тормозит автоматизацию сценариев обновления через Espresso.
Опять же, Appium может автоматизировать эти сценарии.

Скриншот

Это дополнительная часть, не относящаяся напрямую к недостаткам Эспрессо. Но, так или иначе, здесь есть много интересных моментов, подсказок и хитростей, позволяющих упростить процесс изготовления скриншотов, который не так прост, как вы думаете.

Все это мешает писать чистые, стабильные, поддерживаемые и понятные UI-тесты! И все команды, решившие писать автотесты, вынуждены бороться с этими проблемами. Это отстой.
Поэтому мы (разработчики из Лаборатории Касперского, Avito, HeadHunter) решили объединиться, чтобы подготовить единую библиотеку для устранения этого недостатка.

Встречайте новую уникальную библиотеку — Kaspresso !

Мы написали серию статей о том, как Kaspresso решает ваши любимые задачи.
Первый касается проблем с читабельностью, нестабильностью, логированием и архитектурой UI-тестов.

Поехали!

Начнем с того, что библиотека Kakao собирается улучшить читабельность. Kakao — красивая DSL-обертка над Espresso.
Просто сравните два фрагмента кода, представляющие один тест.
Первый код написан с помощью Espresso:

Второй код написан с помощью Kakao:

Довольно впечатляюще.
Вы можете заметить использование таких вещей, как MainScreen . MainScreen является реализацией шаблона Page Object:

Вкратце, Page Object описывает представления, расположенные на экране. Более подробное объяснение будет чуть позже. Итак, Kakao призывает нас писать тесты на основе PageObjects.

Здесь начинается настоящее приключение. Хочу обратить ваше внимание на то, что не существует хороших и чистых решений для решения проблем с flaky и логированием. Но мы постарались восполнить этот недостаток. Что мы получили?

Как вы помните, Espresso не предоставляет никакого механизма для обработки ошибок с перезапуском неудачных действий и не добавляет автоматических журналов. Посмотрите на всю схему:

Если мы действительно хотим управлять Эспрессо, то мы должны поставить перехватчики между Пользователем и Эспрессо. Они будут отвечать за обработку ошибок, перезапуск неудачных действий и логирование, как на следующем рисунке:

Как здесь установить перехватчики? На что это похоже? Чтобы ответить на этот вопрос, давайте погрузимся в эспрессо!

Посмотрите еще раз на тест Espresso:

Мне очень нравится этот API. Так читабельно и ремонтопригодно. Довольно круто. (сарказм=))
Но давайте преобразуем код в блок-схему для упрощения восприятия Эспрессо:

Теперь рассмотрим блок-схему пошагово:

1. Метод onView с ViewMatcher , переданный в качестве аргумента, помогает получить специальный класс, описывающий View, с которым мы работаем.
   Имя этого класса — ViewInteraction.
2. ViewIntercation — самый основной и важный класс в Espresso.
   Все действия и утверждения над представлением доступны только через класс ViewIntercation .
3. На самом деле все действия и утверждения над представлением доступны через два метода ViewIntercation . Это методы выполнения и проверки . Эти методы делают много разных вещей с MainLooper, представлениями, асинхронными операциями и другими под капотом. В аргументах задаем реализации простых интерфейсов: ViewAction и ViewAssertion , с помощью которых мы устанавливаем правила для конкретных действий или утверждений, которые мы хотим выполнить.

Теперь вспомним начальную схему взаимодействия User-Espresso:

При включении вышеперечисленных интерфейсов и классов трансформируется в:

Думаю, следующий шаг вы предскажете. Хорошо, просто оберните выполните методы и проверьте методы для управления эспрессо:

Этот новый промежуточный слой является идеальным кандидатом, куда мы можем поместить наши перехватчики. Что это за перехватчики и как они выглядят?

Мы реализовали два вида перехватчиков: BehaviorInterceptor и WatcherInterceptor.

BehaviorInterceptor

Теперь мы сосредоточимся на примере с методом viewIntercation.perform . Все, что мы собираемся обсудить, абсолютно идентично для viewIntercation.check .

BehaviorInterceptor является текущей оболочкой viewIntercation.perform .
Перехватчик отвечает за:

1. Вызов viewIntercation.perform столько, сколько вам нужно.
2. Обработка результата каждого выполнения viewIntercation.perform .

Код выглядит следующим образом:

Первой реализацией behaviorInterceptor является FlakyBehaviorInterceptor для преодоления проблемы нестабильности. См. проект реализации FlakyBehaviorInterceptor :

Обратите внимание на параметр action . В нашем случае это viewInteraction.perform(ViewAction) . Вызов действия обернут конструкциями try-catch и do-while, которые мы можем обрабатывать и управлять поведением Espresso.

В случае ошибки flakyBehaviorInterceptor перехватывает исключение и повторяет вызов через intervalMs период. Количество попыток выполнения действия ограничено параметром timeoutMs .

Но мы не остановились только на FlakyBehaviorInterceptor .

Например, еще один распространенный сбой — невидимость вида на экране. Вам просто нужно прокрутить родительский макет, чтобы сделать ваш вид видимым. Удивительно, но Espresso не может этого сделать и выдает исключение. Вот почему был разработан AutoscrollBehaviorInterceptor .

Еще одна причина флажков – случайное появление системных диалогов андроида, особенно на реальных устройствах. Чтобы решить эту проблему, мы написали SystemDialogBehaviorInterceptor 9.0311 .

Имейте в виду, что принцип описанных перехватчиков работает как русская матрешка. Взгляните на изображение ниже:

FlakyBehaviorInterceptor вызывает AutoscrollBehaviorInterceptor , AutoscrollBehaviorINterceptor вызывает SystemDialogBehaviorInterceptor , SystemDialogBehaviorInterceptor , SystemDialogBehaviorInterceptor , SystemDialogBehaviorInterceptor , SystemDialogBehaviorInterceptor , SystemDialogBehaviorInterceptor , SystemDialogBehaviorInterceptor , SystemDialogBehaviorInterceptor code. Но обработка результата идет обратным путем.

WatcherInterceptor

Второй вид перехватчиков — WatcherInterceptor .
WatcherInterceptor не может повлиять на поведение Espresso. Зато может получить много полезной информации о конкретном действии. Такая информация находится в ViewAction . Благодаря этим данным вы можете создавать, например, более богатые, понятные и читаемые журналы. Итак, как получить такую ​​информацию?

Мы представили класс ViewActionProxy , который выглядит следующим образом:

Черновик реализации ViewActionProxy:

Как видите, мы просто вызываем все watcherInterceptors и отправляем им всю необходимую информацию о конкретных viewAction и view . После этого действия мы вызываем оригинальный viewAction.perform .

Наш по умолчанию WatcherInterceptor регистрирует каждое действие и утверждение каждого представления. Взгляните на пример ниже:

Гениально, не так ли? Концепция действительно интересная и гибкая. Никто не мешает добавить дополнительные перехватчики и модифицировать обычное поведение Espresso. Но где находятся все перехватчики? Как это организовано?

Во-первых, полной оболочкой Espresso является Kakao, который скрывает все взаимодействия с ViewInteraction, onView и другими внутренними вещами Espresso. Именно поэтому мы добавили поддержку перехватчиков в библиотеку Kakao (версия 2.1).

Во-вторых, мы написали библиотеку, обеспечивающую простой и удобный способ управления перехватчиками; он предоставляет богатый набор перехватчиков по умолчанию, обрабатывающих ненадежные тесты, улучшающих ведение журнала и тому подобное. А название этой библиотеки вы знаете — Kaspresso .

Посмотрите пример того, как это работает с простым тестом, написанным с помощью Kakao:

Как включить все перехватчики по умолчанию, то есть перехватчики поведения и наблюдателя?
Вам просто нужно добавить следующее:

TestCase — это специальный родительский класс, создающий всю магию. Здесь наш тест обрабатывает нестабильность и может выводить более подробные журналы. Это довольно сексуально =)

Sweety cookies

Ранее описанные перехватчики позволили нам реализовать несколько очень привлекательных функций. Смотри ниже.

flakySafety
Это метод, который получает лямбду и вызывает ее так же, как это делает FlakyBehaviorInterceptor . Если вы отключите этот перехватчик или если вы хотите установить некоторые специальные ненадежные параметры безопасности для любого представления, вы можете использовать этот метод.

постоянно
Эта функция похожа на то, что делает flakySafely , но для негативных сценариев, где нужно все время проверять, что не происходит чего-то .

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

Были ли у вас когда-нибудь рекомендации по написанию обычных UI-тестов? Я не уверен, что у вас есть. Но когда команда разработчиков начинает писать автотесты без какого-либо стиля кода и правил, то результат может быть непредсказуемым.
Итак, что мы предлагаем? Мы собираемся разделить все рекомендации на две большие группы: Абстракции и Структура теста.

Абстракции

Эта часть построена в формате вопрос-ответ.

Сколько абстракций вы можете использовать в своих тестах?

Только один! Это объект страницы (PO), термин, хорошо объясненный Мартином Фаулером в этой статье. Как мы уже говорили, Page Object описывает представления, расположенные на экране. Это делает ваш код чище.
В Какао а Экран класс является реализацией ПО. Каждый видимый пользователем экран, даже простой диалог, должен быть отдельным ПО.
Конечно, бывают случаи, когда нужна новая абстракция и это нормально. Но наш совет — хорошо подумать, прежде чем вводить новую абстракцию. Меньшее количество абстракций упрощает возможность вовлечения тестировщиков и автотестировщиков в процесс написания автотестов.

Это нормально, что ваш заказ на покупку содержит вспомогательные методы?

Если эти методы помогают понять, что делает тест, то все в порядке.
Например, сравните две части кода:

и

Я уверен, что метод navigationToTasksScreen() более "явный", чем простой щелчок на каком-нибудь ShieldView .

Может ли объект страницы содержать внутреннее состояние или логику?

Нет! Page Object не имеет внутреннего состояния или логики. Это всего лишь описание пользовательского интерфейса конкретного представления. Помните о принципе единой ответственности.

Утверждение методов справки внутри Page Object. Это уместно?

Опытные автотестировщики, которые занимались автоматизацией тестов в приложении Desktop, могут помнить о потенциально огромных размерах Page Objects в случае, когда разработчик помещает внутри PO много вспомогательных (assert) методов, как это предлагается в статья Мартина Фаулера.

Но мобильные и настольные приложения — это разные вещи. И, конечно же, размер экрана на мобильном телефоне и размер экрана на рабочем столе тоже разные. Поэтому мы не видим препятствий для добавления методов assert в PO.
Чтобы понять преимущества такого подхода, просто сравните три фрагмента кода:

Третий код был вдохновлен советом Мартина Фаулера в упомянутой статье.
Подводя итог, мы за первый вариант.

Проверьте этот простой пример:

У нас есть два экрана и три действия. Можете ли вы предсказать, как этот тест коррелирует с тестовым набором, на котором он основан? Сколько шагов в тестовом примере? Сомневаться.
Что здесь может сделать разработчик? Первый способ - поставить комментарии:

Хорошо. Но мы также хотим видеть, какой шаг выполняется в журналах теста.
Выполним код:

Мы добавили логи в тест. Неплохо.
Еще одна полезная функция — перехватывать потенциальные исключения на каждом этапе. В случае исключения мы хотим вывести дополнительную информацию в логи и сделать скриншот.
Текущий код трансформируется в:

Тьфу. Вы видите, как ваш простой тест превращается в настоящий беспорядок. Поддерживать такой код слишком сложно.

Вот почему мы создали специальный вид «Kotlin» DSL, чтобы выполнить все наши пожелания, оставив код без существенных изменений.
Этот DSL выглядит следующим образом:

Метод шаг делает все то, что мы обсудили:

• автоматическая регистрация
• отлов исключений
• снимок экрана после ошибки
• и т.д. Теперь ваш тест состоит из
отдельных и логичных шагов с понятными названиями и огромной логикой под капотом:

Просто оцените журналы шаг Функция выдает:

Отлично!

Дополнительные возможности нашей DSL

В процессе автоматизации DSL развивалась и совершенствовалась. Что еще мы добавили в DSL?

Сценарий

«Сценарий» — это группа шагов, которые повторяются практически во всех тестах. Ниже приведен пример:

Внутренний шаг

Иногда бывает полезно выделить каждое утверждение в одном шаг или сделать что-то подобное. В этом случае можно использовать «внутренний шаг»:

Подготовка среды

Эта часть также является продолжением предыдущей части. Но мы рассмотрим немного другую задачу.

Очень часто перед запуском теста необходимо подготовить устройство или среду. Например, перед тестом нужно отключить сеть. Что мы можем сделать?

Мы добавили нулевой шаг для отключения сети.
Ключевой задачей здесь является восстановление исходного состояния среды устройства. Мы настоятельно рекомендуем восстанавливать среду устройства после каждого теста, чтобы избежать потенциальной нестабильности для будущих тестов.

Честно говоря, эти два шага не являются частью теста.