Блог компании агентство agima

Привет! На связи снова AGIMA, и сегодня мы расскажем о ботах. А точнее о потенциально опасных ботах, способных нанести серьезный ущерб вашему веб-сервису. Эта проблема остается актуальной уже несколько лет, но, к сожалению, многие до сих пор не до конца осознают ее серьезность. Какими же бывают вредные боты, как они действуют и почему защита сервиса от них по-настоящему важная задача? Давайте разберемся.

Типы вредоносных ботов

• Программы для автоматизированного подбора логина и пароля (брутфорс) специализируются как на получении доступа уровня Администратор, так и на банальную кражу учетных записей пользователей сервиса. А в некоторых случаях с их помощью можно получить действующий список живых email-адресов для спам-рассылки или фишинга. Пример: при авторизации на сайте подставляем случайные значения в поля email и пароль. В этой ситуации правильность пароля не важна. Если логин (email) есть в базе, мы узнаем об этом по таймингу ответа сервера. Сохраняем email, и добавляем его в базу спам рассылок.

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

• Спам-боты могут автоматически оставлять в обсуждениях негативные комментарии или вредоносные ссылки на якобы полезные ресурсы. Некоторые из таких программ умеют регистрироваться на ресурсе, если это необходимо для написания комментариев. Негативные и оскорбительные комментарии повышают репутационные риски. Стоит вспомнить об опыте бьюти-бренда Z Palette, который мог стать культовым, но не успел его буквально похоронил один-единственный провокационный комментарий. Или историю одного из гигантов рынка цифровой техники Dell. В далеком 2005 году этот знаменитый бренд едва не был нокаутирован всего одним негативным отзывом.

• Парсинг-боты, задействованные в веб-скрейпинге, умеют собирать практически любой контент с веб-ресурсов. Воровство контента позволяет мониторить предложения конкурентов, чтобы затем агрегировать информацию, нужную для выстраивания бизнес-стратегии. И даже если вы не против поделиться информацией с конкурентами и отдать их ботам весь контент, находящийся на вашем сервисе, такие набеги на ресурс могут сильно замедлить его работу и испортить аналитику. Чтобы не останавливаться на частностях, приведем ссылку на полезную и очень подробную статью о веб-скрейпинге.

• Продвинутые боты могут имитировать действия настоящего пользователя. Их используют для взлома учетных записей, кардинга, мошенничества с покупками и других серьезных атак. Кстати, DDoS тоже реализуется с помощью ботов, которые распределены территориально и одновременно задействуются в момент атаки. К счастью, сейчас есть много сервисов для защиты от атак этого типа. Вот один из них: https://qrator.net/ru. Сервис обеспечивает эффективную защиту в автоматическом режиме, с максимальной скоростью реакции на каждую угрозу. При этом количество ложных срабатываний защиты не превышает 5%.

Выстраиваем защиту от ботов. Что сделать в первую очередь?

Полностью оградиться от ботов невозможно. Но снизить их активность на вашем ресурсе вполне реально. Механизмы защиты могут быть самыми разными от несложных настроек в бэкенде и white\black-листов до многоуровневых систем аналитики трафика с возможностью обучения и распознавания вредоносной активности.

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

Не стоит забывать, что боты, даже не наносящие прямого финансового ущерба бизнесу, могут сильно навредить аналитике. Впоследствии будет сложно сделать выводы по посещаемости, конверсии, востребованности товаров и т.д. Придется потратить время на очистку данных от воздействия ботов, если она вообще будет возможна.

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

Как сократить активность ботов на сайте?

• Один из самых простых и популярных инструментов Captcha. Она добавляет некую задачу, чаще всего графическую, которую пользователь должен решить при заполнении формы регистрации, входа, обратной связи и др. Это защита от брутфорса, спам-ботов и ботов авторегистрации. Но некоторые вредоносные программы умеют обходить ее. Ключевой барьер для использования Captcha ее неудобство для легитимных пользователей ресурса. Людей часто напрягает эта бессмысленная процедура, особенно если определить ответ не удается с первого раза и приходится тратить время на повторные попытки. Это может немного снизить конверсию. Решение использовать или не использовать этот инструмент зависит от оценки рисков и аналитики: если видно, что пользователи часто бросают попытки заполнить форму из-за капчи, стоит подумать над упрощением механизма в этом месте. Кстати, вот статья с интересным кейсом использования капчи (точнее, антикапчи).

• reCAPTCHA v3 сервис, созданный для борьбы с ботами, который основывается на агрегации действий пользователей и поведенческом анализе. И в отличие от классической captcha, не видима обычному пользователю. Подгружается она как JS библиотека и отслеживает поведение пользователя, затем информация отправляется в сервисы google для вынесения вердикта.Не смотря на лояльность такой защиты к пользователям ресурса, данный способ защиты может отрицательно повлиять на скорость загрузки страницы и снизить баллы по Google PageSpeed Insight. Ну и ошибки при поведенческом анализе никто не отменял. При целевой атаке на ресурс полагаться только на данный способ защиты не стоит.

• Защита от брутфорса может быть реализована лимитом на количество неверных попыток для ввода данных. Сейчас разработчики используют этот способ практически по умолчанию. Однако лишний контроль не помешает.

• Можно настроить на сайте ловушки для ботов (honeypot). Например, добавить скрытое от пользователя поле. Обычный пользователь видит нужное ему поле для заполнения, а бот видит еще одно в коде и заполняет его. После этого бот блокируется скриптом. Против умных ботов такая защита срабатывает не всегда, но отбросить часть ненужного трафика она точно поможет. Также можно установить таймер на заполнение полей (сообщения, комментарии и т.д.). Боты обычно вносят данные в поля моментально, в отличие от живых людей это помогает идентифицировать их и блокировать их дальнейшие действия. С ловушками можно экспериментировать и адаптировать их к своему сервису. Этот способ борьбы с ботами даст возможность снизить их активность на ресурсе, но, увы, не избавит вас от них: если кто-то будет целенаправленно атаковать именно ваш сервис, он сможет просто проанализировать вашу форму и алгоритмы и внести изменения в действия своего бота.

• Также существуют специализированные решения от таких производителей как Akamai, Imperva, Radware, PeremeterX и др., которые применяют подходы на основе анализа данных. Машинное обучение направлено на поведенческий анализ для обнаружения аномалий в трафике веб-сервиса. Анализируя трафик огромного количества интернет-ресурсов, такие инструменты оценивают каждый запрос и определяют вероятность того, что он поступает от бота. При этом учитывается структура защищаемого приложения. Со временем система адаптируется к каждому веб-сервису, и вероятность ложных срабатываний (отклонений запросов настоящих пользователей) минимизируется. Легитимный трафик отделяют от вредоносного в том числе и на основе отпечатка, состоящего из IP адреса, геолокации, браузеров и ряда других идентификаторов. Некоторые решения весьма эффективные, по мнению аналитиков Gartner умеют тестировать структуру сервиса на проникновение ботов, показывая все области, где присутствуют риски для сайта (и, соответственно, бизнеса). Такую защиту уже действительно сложно обойти, но все же возможно если долго и упорно в ней разбираться. Ключевой минус подобных решений высокая цена.

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

А теперь небольшой инсайт. Мы в AGIMA создаем десятки веб-сервисов в год. И каждому второму проекту, который мы разрабатываем, нужна настройка обороны от вредоносных программ. В нашей практике встречались случаи, когда после внедрения определенных мер количество нежелательного трафика на сервис сокращалась на 20-40%, а нагрузка на серверные платформы и бэкенд на 15-30%. Это достаточно ощутимый результат для высоконагруженных веб-сервисов.

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

Затягивать с поиском решения не стоит, промедления могут обернуться существенными потерями. Вот пример: по данным Financial Times, на сегодняшний день из-за активности ботов ведущие стриминговые сервисы (Spotify, Amazon, Universal Music Group, Warner Music и др.) теряют в общей сложности около 300 миллионов долларов в год! Кто знает, возможно, своевременный анализ рисков помог бы этого избежать. Так что угрозу вредоносных ботов никак нельзя игнорировать. Но не стоит и паниковать варианты защиты найдутся в любом случае!

Статья написана совместно с Алексеем Клиновым, Ex-Head of Information Security, AGIMA.

Привет, Хабр!

Меня зовут Ваня Антипин, я Deputy CTO в компании AGIMA. Сегодня я постараюсь вам рассказать про роль техлида в компании. Напомню, что в октябре 2020 года мы говорили о роли тимлида в компании и команде. Если кратко от тимлида зависит многое, включая эффективность команды, достижение поставленных целей, оперативное решение рабочих тасков.

А что насчет техлида? Об этой специальности говорят не так часто, но техлиды важны и нужны не менее тимлидов. Более подробно я рассказываю об этом на курсе Руководитель команды разработки и делюсь реальными кейсами. Но не будем отвлекаться, приступим!

Техлид не специальность, а роль

Главное, что нужно знать о техлиде то, что это роль. Она может быть формальной, и может быть и номинальной, все зависит от проекта и команды. Так, техлидом может стать и чаще всего становится опытный инженер, который не только оперативно справляется с собственными задачами, но и может помочь коллегам, беря на себя дополнительные технические задачи и ответственность за них.

Что касается формальной или номинальной роли, то в классическом Scrum, например, нет роли техлида, а вот в проектах и командах, которые живут по Scrum, техлид есть.

Когда нужен техлид? В целом, он будет полезен практически везде и всегда, но особенно важна эта роль на больших проектах, где много задач, насыщенная архитектура и команда состоит из 3-х и более человек.

А что насчет обязанностей?

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

Пример разработка мобильного приложения. Если проект большой, то здесь обязанности техлида и тимлида редко пересекаются. Так, техлид отвечает за архитектуру мобильных приложений под две платформы, iOS и Android, за проектирования REST API в контексте разрабатываемой мобильной архитектуры. А вот за управление проектом, разработку серверной реализации API и результаты всего проекта отвечает тимлид.

Если проект не очень большой, то случается, что тимлид забирает на себя задачи техлида это те самые hard-скиллс, которые нужны тимлиду наравне с soft-скиллс.

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

Техлиды и тимлиды зоны ответственности

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

Мы сразу провели границу между тимлидами и техлидами. Техлид это упор на Hard-скиллс, а тимлид на Soft-скиллс. Граница в соотношении этих навыков, причем в зависимости от контекста, заданного проектом и командой.

Для того чтобы прояснить ситуацию, приведу пример. Это кросс-платформенные проекты с сервис-ориентированной архитектурой по разработке омниканальных цифровых витрин. В рамках такого проекта разрабатываются web&mobile-приложения, сервисы управления контентом, сервисы интеграции и реализации бизнес-логики (API). В таком проекте может быть целая команда лидов:

• Тимлид, управляющий процессами, коммуникациями и бюджетом.

• Техлиды для каждой платформы, отвечающие за технические аспекты архитектуры и реализацию решений.

Разберемся детальнее с распределением ответственности между тимлидом и техлидом на примере процесса управления разработкой в контексты реализации фичей из бэклога. Процесс может быть таким:

1. Списком задач в бэклоге управляет руководитель проекта. Задачи по разработке уходят в работу на тимлида.

2. Тимлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости уточняет детали или дополняет описание задачи описанием уточнением требований или описанием возможной реализации. Задача уходит в работу на техлида. При этом на проекте работает три техлида: фронт, бэк, мобилка; и тимлид понимаем из описания, на кого делегировать задачу.

3. Техлид получает задачу, проверяет точность и полноту требований в задаче, при необходимости дополняет описание задачи своей экспертизой в предметной области, может описать реализацию или уточнить по реализации предложенной тимлидом.

4. Техлид определял исполнителя и отдаёт задачу в работу.

5. Задача от разработчика возвращается на код-ревью к техлиду и техлид принимает задачу или отправляет на доработку с комментарием содержащим уточнения и рекомендации.

В таком процессе за техническое качество реализации отвечает техлид, а тимлид за сроки и бюджет.

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

Знания, умения и скиллы поговорим конкретнее

Важный момент в понимании сути работы техлида состоит в том, что техлид это эксперт. В то же время далеко не каждый эксперт техлид. Выше мы говорили, что техлид это, в основном, про Hard-скиллы. Но он должен владеть и определенным набором Soft-скиллов, ведь ему тоже нужно коммуницировать внутри команды, а также управлять знаниями о технологиях.

Базовый набор Soft-скиллс:

• Поиск и подбор кандидата, собеседование.

• Постановка личных целей.

• Стратегическое видение развития.

• Отношения с людьми: эмпатия и эмоциональный интеллект.

Базовый набор Hard-скиллс:

• Знание языков разработки и опыт программирования. Знание сопутствующих и окружающих этот стек технологий.

• Понимание архитектуры проекта: принципы проектирования архитектуры, паттерны и инструменты.

• Процессы и инструменты тестирования. Оптимизация тестирования, метрики и мониторинг.

• Управление инцидентами.

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

• Текстовые редакторы и интегрированные среды разработки.

• Инструменты для создания схем в разных графических нотациях и офисные программы.

• Системы управления задачами и проектом.

• Системы управления знаниями и документаций.

• Системы управления версиями кода и инструменты CI/CD.

• Системы контейнеризации и инструменты DevOps.

• Системы мониторинга и управления инцидентами.

• Серверные операционные системы и их сервисы.

• Скрипты и собственные наработки кода.

Кто может стать техлидом?

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

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

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

Привет, Хабр!

Меня зовут Игорь, я Head of Mobile в компании AGIMA.

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

Важно: в примере кода на github будет полноценный пример с вводом номера телефона и кодом, но экран ввода номера телефона совсем скучный, поэтому сегодня мы вводим код :)

Выглядит не очень сложно, но, если присмотреться, функционал экрана довольно большой, а именно:

• отправить код на сервер;

• включить таймер повторной отправки + отобразить визуально;

• после завершения таймера показать кнопку отправить еще раз;

• отправить повторный запрос на получение кода;

• отобразить все ошибки;

• обработать успешное подтверждение кода.

Если попробовать разделить экран на UI и логику, получается примерно такое взаимодействие между логикой и интерфейсом.

Можно, конечно, отправить всю логику про таймеры и isLoading на View слой, но мне больше нравится относить это к логике. Особенно учитывая то, что я большой поклонник MVVM+Rx (и буду это использовать в статье), это более чем уместно смотрится. Ну да ладно.

ViewModel в этом случае играет роль некоего преобразователя пользовательских действий: у нее есть input и output (видно на картинке выше). За навигацию будет отвечать кто-то еще, например, координатор.

Со стороны UI нам будут интересны следующие компоненты:

final class ConfirmCodeViewController: BaseViewController {  /// поле ввода кода  private lazy var codeTextField = CodeTextField()  /// лейбл для отображения ошибок   private lazy var errorLabel = UILabel()  /// один лоадер для запросов на отправку кода и на повторный запрос кода  private lazy var loader = UIActivityIndicatorView()  /// лейбл с обратным отсчетом для повторной отправки кода  private lazy var timerLabel = UILabel()  /// кнопка повторной отправки кода  private lazy var retryButton = UIButton(type: .system)  /// это все будет в стеквью  private lazy var stackView = UIStackView()}

ViewModel будет выглядеть так:

/// Например, после успешного подтверждения кода нам могут предложить ввести перс. данныеenum AuthResult {case successcase needPersonalData}protocol ConfirmCodeViewModelProtocol {    /// Введенный пользователем код для подтверждения    var code: AnyObserver<String> { get }        /// Пользователь нажал на отправить повторно    var getNewCode: AnyObserver<Void> { get }        /// Результат подтверждения кода    var didAuthorize: Driver<AuthResult> { get }        /// Один индикатор на все запросы на этом экране    var isLoading: Driver<Bool> { get }        /// Ошибки из всех запросов на этом экране    var errors: Driver<String> { get }        /// Таймер отправки нового кода    var newCodeTimer: Driver<Int> { get }        /// Запросили новый код при нажатии на отправить заново    var didRequestNewCode: Driver<Void> { get }      /// Таймер отправки нового кода запущен    var codeTimerIsActive: Driver<Bool> { get }}

Обратите внимание, что при таком подходе мы стараемся не использовать PublishSubject, BehaviourRelay итп, чтобы четко разделить input и output у ViewModel. Теперь давайте это все свяжем.

View отдает следующие потоки данных:

let codeText = codeTextField.rx.text.share()codeText    .bind(to: viewModel.code)    .disposed(by: disposeBag)retryButton.rx.tap    .bind(to: viewModel.getNewCode)    .disposed(by: disposeBag)

ViewModel будет как-то (покажу ниже) обрабатывать ввод кода пользователя, а также делать запрос на повторную отправку кода, если мы нажмем на кнопку.

Сначала давайте посмотрим ViewModel целиком, далее разберем ее более подробно.

ViewModel рассмотрим по кусочкам:

let _codeSubject = PublishSubject<String>()self.code = _codeSubject.asObserver()let codeObservable = _codeSubject.asObservable()let validCodeObservable = codeObservable.filter { $0.count == codeLength }

_codeSubject это поток данных из textfield ввода кода.

validCodeObservable отфильтровывает значения нужной длины, которые мы будем отправлять на сервер.

Выше мы договорились, что PublishSubject не используем, но внутри нам от того же кода нужен не только AnyObserver, но и Observable , чтобы использовать его, например, для отправки кода на сервер. В дальнейшем я планирую использовать такую технику: AnyObserver или Observable в публичном интерфейсе и PublishSubject внутри.

let codeEvents: Observable<Result<Void, Error>> = validCodeObservable    .flatMap { (code) in        authService.confirmCode(code: code, token: token).materialize()    }.share()

Собственно, отправка кода на сервер :) Обращаем внимание на .materialize(). Поскольку мы планируем использовать этот Observable в реактивных цепочках, мы не хотим получить ошибку и прерывать их. materialize позволяет завернуть все значения и ошибки в Result<Value, Error> и тем самым мы никогда не прервем реактивную цепочку из-за ошибки.

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

Состояние загрузки

Здесь довольно интересный момент. Если мы получили валидный код, готовый к отправке, то мы отображаем интерфейс загрузки. Если мы получили ответ от сервера, это означает, что нам надо скрыть состояние загрузки. Таким образом, мы можем взять эти потоки данных (на примерах выше), смаппить их в true или false и забиндить в isLoading.

didAuthorize = codeEvents.elements()...

.elements() работает как фильтр и пропускает только значения из codeEvents и игнорирует ошибки. Напомню, что тип значений у codeEvents это Result<Void, Error> , что является частью RxSwiftExt.

Таймер повторной отправки кода

Таймер включается при следующих событиях:

• мы отправили код на подтверждение (validCodeObservable.mapTo(Void()));

• мы перезапросили код (didRequestNewCode);

• сразу же при заходе на экран (.startWith(Void())).

Именно это описано в строчке Observable.merge... Сам таймер делается стандартными средствами RxSwift. Останавливаем таймер с помощью оператора take(while:), пока значение таймера не станет равно 0.

Лейбл с таймером и кнопка переотправить должны скрываться/показываться в зависимости от того, активен ли таймер:

viewModel.codeTimerIsActive    .drive(retryButton.rx.isHidden)    .disposed(by: disposeBag)        viewModel.codeTimerIsActive    .not()    .drive(timerLabel.rx.isHidden)    .disposed(by: disposeBag)

За ошибки отправки и запроса нового кода у нас будет отвечать один поток данных errors.

errors = codeEvents.errors().merge(with: fetchNewCode.errors())            .compactMap { ($0 as? ErrorType)?.localizedDescription }            .asDriver(onErrorJustReturn: "")

Также запретим редактировать код, во вркмя того, как он отправляется:

viewModel.isLoading    .not()    .drive(codeTextField.rx.isEnabled)    .disposed(by: disposeBag)

ViewModel получилась довольно-таки тестируемая, поэтому давайте напишем тесты! Я приведу примеры тестов, которые будут показывать, как ViewModel реагирует на пользовательский ввод. Создадим вспомогательный метод, который будет создавать поток событий ввода кода. Внимание, используется RxTest!

class ConfirmCodeViewModelTests: XCTestCase {    // properties// methods     //MARK:- Helpers    private func bindCodeInputEvents(        _ events: [Recorded<Event<String>>] = [.next(100, "1"), .next(200, "11"), .next(300, "111"), .next(400, "1111")])    {        codeInputEvents = scheduler.createHotObservable(events)        codeInputEvents.bind(to: viewModel.code).disposed(by: disposeBag)    }}

Например, таймер отправки нового кода должен запускаться и корректно отрабатывает сразу после открытия экрана напишем вот такой тест:

   func test_timerInvokedAutomatically() {        let sut = scheduler.start(created: 0, subscribed: 0, disposed: 1000) { self.viewModel.newCodeTimer }        XCTAssertEqual(sut.events, [.next(1, 2), .next(2, 1), .next(3, 0)])    }

Или вот такой: проверим, что у нас передается на UI событие об ошибках

 func test_errorEmmitedValueAtFailure() throws {        bindCodeInputEvents()        setConfirmCodeResult(.error(0, MockError.confirmFailure))         let sut = scheduler.start { self.viewModel.errors }        XCTAssertEqual(sut.events, [.next(400, "confirmFailure")])    }

Полный код тестов, да и вообще весь пример можно найти тут. Требования могут слегка меняться от проекта к проекту (например, код можно отправлять по кнопке а не автоматом), но этот код достаточно несложно приспособить к подобным изменениям.

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