Меня зовут Владислав Романенко, я Senior iOS QA Engineer в Badoo и Bumble. Мы регулярно внедряем новые фичи в приложения, и автоматизация тестирования — один из способов не пропустить баги. Фактически автотесты входят в жизненный цикл всех частей наших приложений: бэкенда, сервисов, фронтенда и мобильных клиентов. Чем раньше мы обнаружим ошибку, тем дешевле будет её исправить. 

Сегодня я расскажу об автоматизации тестирования в iOS, потому что на протяжении всей своей карьеры в Badoo я плотно занимался тестированием наших нативных iOS-приложений, которые написаны на Objective-C и Swift. Хотя кое-где я буду упоминать характерные для iOS инструменты и термины (например, XCTest), общие принципы и подходы универсальны. Так что, даже если в вашем проекте используется совсем другой стек, статья будет вам полезна.

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

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

В одном из моих личных проектов я решил использовать Jetpack Compose в качестве основной технологии. Это означало, что моё приложение будет иметь одну Activity, а вся навигация будет выполняться с помощью Compose. Когда я начал планировать проект, библиотеки Compose Navigation ещё не было, как не было и способа внедрить ViewModel в Composable без использования компонентов Activity, Fragment или View. 

Но примерно за полгода до публикации этой статьи появилась библиотека Jetpack Compose Navigation, и Dagger-Hilt стал поддерживать Compose. Сегодня я расскажу о моём пути: поделюсь видением проблемы масштабируемости навигации на примерах Google и предложу её возможное решение.

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

В этой статье описан мой опыт по написанию плагина для компилятора Kotlin. Моей главной целью было создание плагина под iOS (Kotlin/Native), аналогичного kotlin-parcelize под Android. Дело в том, что в iOS, как и в Android, приложения тоже могут быть убиты системой, а значит, может возникнуть необходимость сохранять стек навигации и другие данные. В результате работы над этой задачей получился kotlin-parcelize-darwin. Подробности о его создании и применении — под катом.

Меня зовут Руслан, я релиз-инженер в Badoo и Bumble. Недавно я столкнулся с необходимостью оптимизировать механизм автомерджа в мобильных проектах. Задача оказалась интересной, поэтому я решил поделиться её решением с вами. В статье я расскажу, как у нас раньше было реализовано автоматическое слияние веток Git и как потом мы увеличили пропускную способность автомерджа и сохранили надёжность процессов на прежнем высоком уровне.

Меня зовут Евгений Тупиков, я ведущий PHP-разработчик в Badoo и Bumble. У нас в команде более 200 бэкенд-разработчиков, которые работают над сотнями модулей и отдельных сервисов в наших приложениях. Но поначалу всё было не так масштабно. В 2006 году это был один проект, над которым работала небольшая команда. Каждый разработчик хорошо понимал, как всё устроено: легко ориентировался в коде, знал, какие есть сервисы и как они взаимодействуют между собой. Однако по мере роста проекта всё больше времени занимал поиск «хранителей знаний» — тех, кто отвечает за ту или иную функциональность и к кому можно обратиться с вопросом или предложением. 

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

Меня зовут Владислав Романенко, я старший iOS QA Engineer в Badoo и Bumble. Несколько лет назад мы начали активнее использовать автотесты в процессе разработки, но столкнулись с несколькими трудностями на этом пути. 

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

Сложности в разработке часто решаются с помощью паттернов — обобщённых решений для часто возникающих проблем в заданном контексте. То же и с автоматизацией тестирования, есть даже удобное wiki-описание. В этой статье мы поговорим о паттернах процессов (Process Patterns). Они помогают организовать и улучшить процесс автоматизации тестирования. 

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

В этом году должен выйти PHPUnit 10 (релиз планировался на 2 апреля 2021 года, но был отложен). Если посмотреть на список изменений, то бросается в глаза большое количество удалений устаревшего кода. Одним из таких изменений является удаление метода MockBuilder::setMethods(), который активно использовался при работе с частичными моками. Этот метод не рекомендуется использовать с версии 8.0, но тем не менее он описан в документации без каких-либо альтернатив и упоминания о его нежелательности. Если почитать исходники PHPUnit, issues и пул-реквесты на GitHub, то станет понятно, почему так и какие есть альтернативы.

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

Меня зовут Дмитрий Макаренко, я Mobile QA Engineer в Badoo и Bumble: занимаюсь тестированием новой функциональности в наших приложениях вручную и покрытием её автотестами. 

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

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

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

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

Kotlin имеет много классных особенностей: null safety, smart casts, интерполяция строк и другие. Но одной из самых любимых разработчиками, по моим наблюдениям, являются data-классы. Настолько любимой, что их часто используют даже там, где никакой функциональности data-класса не требуется.

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

Файлы конфигурации (конфиги) — неотъемлемая часть большинства приложений, но, как показывает практика, это не самая популярная тема для обсуждения. Чаще всего разговоры о конфигах ограничиваются обсуждением работы с ними непосредственно в коде: как их структурировать, использовать переменные окружения или нет, где хранить пароли и т. п. 

На мой взгляд, есть и другая сторона работы с конфигами, которая заслуживает внимания, — развёртывание (деплой). За свою карьеру я видел довольно много способов деплоя конфигов и уверен, что каждый может узнать об этом что-то новое.

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

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

В первой части статьи мы поговорили о том, что такое ANR (Application Not Responding), и рассмотрели несколько способов сбора информации об этих ошибках. А сегодня я расскажу о проблемах, которые мы обнаружили в нашем приложении, о том, как мы их исправляли и что из этого в итоге получилось.

Время запуска приложения

Первое, что можно сделать, чтобы уменьшить количество ANR-ошибок, — попробовать найти самые частые причины их возникновения. Начать можно с консоли Google Play — проанализировать самые большие группы ошибок.

Пожалуй, одна из худших проблем, которая может случиться с вашим приложением, — ошибка ANR (Application Not Responding), когда приложение не отвечает. Если таких ошибок много, они могут негативно влиять не только на пользовательский опыт, но и на позицию в выдаче Google Play и фичеринг. 

В начале прошлого года количество ANRs в приложении Badoo превышало порог “Bad Behaviour” в Google Play. Поэтому мы собрали команду для решения этой проблемы и потратили несколько месяцев, экспериментируя с разными подходами. В результате мы смогли уменьшить количество таких ошибок более чем в шесть раз.

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

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

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

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

В этой статье я расскажу:

— как мы не потерялись в сложном графе зависимостей;

— как спасли CI от чрезмерной нагрузки;

— что делать, если с каждым новым модулем приложение запускается всё медленнее;

— мониторинг каких показателей стоит предусмотреть и почему это необходимо.

К 2020 году вы не могли не заметить, что миром правят данные. И, как только речь заходит о работе с ощутимыми объёмами, появляется необходимость в сложном многоэтапном конвейере обработки данных. 

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

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

Я поделюсь несколькими простыми правилами, которые помогают нам в работе с преобразованием данных и, надеюсь, помогут и вам. 

 git show deadbeef 

 git log -p Page.php 

В постах на Хабре тема структурного логирования упоминается часто, но вскользь. Поэтому, когда я наткнулся на эту подробную статью Brandur Leach из Stripe, я решил перевести её и поделиться с сообществом. 

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

В статье Brandur Leach предлагает идею, как открыть еще больше возможностей в структурном логировании. Есть и описание практической пользы от использования такого подхода — в Stripe даже сделали продуктовый функционал на основе данных, полученных из логов, — и детали реализации такого решения (без ухода в дебри конкретного стека технологий).

Приятного чтения!

В iOS-разработке Badoo мы уже несколько лет занимаемся созданием модулей, и большая часть нового кода разрабатывается вне кодовой базы приложений. Сейчас у нас более 100 модулей для Badoo и Bumble. В этой статье я расскажу о нашем опыте и отвечу на самые популярные вопросы о модуляризации: 

— по какому принципу выделять модули; 

— как организовать связи между ними; 

— достаточно ли для фичи одного фреймворка; 

— как сократить время запуска многомодульного приложения; 

— зачем в этом процессе мониторинг;

— можно ли автоматизировать создание новых модулей и так далее. 

Мой коллега, лид команды iOS-разработки и Core-команды Артем Лоенко, в начале года говорил об этом на митапе FunCorp в докладе «Катастрофически полезные последствия модуляризации». Я приведу более подробный разбор процесса модуляризации и некоторых опущенных в его рассказе деталей.