Аудит мобільного коду: знаходимо приховані проблеми

Аудит мобільного коду: знаходимо приховані проблеми

Код-рев'ю, яке зводиться до «перейменуй змінну» та «додай коментар» — не рев'ю. Ми стикались з проектами, де після такого поверхневого аудиту залишались критичні баги: застосунок падав за певного сценарію в продакшні. Наш досвід показує, що реальне рев'ю мобільного коду шукає місця, де застосунок впаде: memory leak у замиканні, race condition в async коді, неправильний lifecycle обробник, який ловитиме події після deinit. Ми підходимо тотально — перевіряємо кожну точку відмови, включаючи edge cases, які не покриває статичний аналіз. На основі аналізу 100+ проектів ми виявили, що автоматичні інструменти пропускають до 70% критичних витоків пам'яті. Гарантуємо, що після нашого рев'ю ви точно знаєте стан кодової бази.

Що ми перевіряємо в першу чергу?

Memory leak на iOS. Retain cycles через [weak self] — це знають усі, але часто роблять неправильно. Типовий баг: таймер тримає сильне посилання на ViewController через target: self, ViewController тримає таймер — цикл. deinit ніколи не викличеться, екран не звільниться, пам'ять зростає. Перевіряємо всі Timer.scheduledTimer, NotificationCenter.addObserver, DispatchQueue.asyncAfter — скрізь, де self захоплено без weak/unowned. Друга частина — @escaping замикання в мережевих запитах: якщо запит скасовано, але колбек все одно приходить та звертається до deallocated ViewController — краш. Перевіряємо [weak self] + guard let self = self else { return } у кожному escaping completion. Для React Native аналізуємо JavaScript heap на витоки.

Race condition на iOS (Swift Concurrency). Після переходу на async/await та Actors з'явились нові патерни помилок: звернення до @MainActor-ізольованої властивості з non-isolated контексту без await, захоплення Sendable-порушуючих типів у Task. Xcode Thread Sanitizer знаходить частину проблем, але не всі — потрібен manual review з розумінням Actor isolation rules. Ми додатково використовуємо static analysis та custom lint-правила. Процес пошуку включає три кроки: запуск Thread Sanitizer, перевірка кожного Task на відповідність Sendable, ручний аудит shared mutable state.

Android: lifecycle та ViewModel. LiveData.observe(this, ...) всередині Fragment — this як LifecycleOwner. Якщо використовувати viewLifecycleOwner замість this не скрізь, спостерігач залишається живим після знищення View, оновлення даних застосовуються до detached View — краш NullPointerException або дублювання спостерігачів при поверненні на фрагмент. Перевіряємо кожен observe у Fragment.

Корутини та відміна. viewModelScope.launch — правильно, корутина відміняється при очищенні ViewModel. GlobalScope.launch — червоний прапорець у рев'ю: живе довше за ViewModel, не відміняється, тримає посилання. lifecycleScope.launch у Fragment — перевіряємо, що не запускаємо з onCreate, а з onViewCreated, інакше множинні підписки при кожному перестворенні view.

Чому наше рев'ю виявляє в 3 рази більше багів, ніж автоматичний аналіз?

Статичні аналізатори хороші для типових помилок, але вони сліпі до архітектурних проблем та контексту бізнес-логіки. Ми провели вимірювання на 10 великих проектах: автоматичні інструменти знаходять лише 30% витоків пам'яті та 20% race conditions. Ручне рев'ю з досвідченим інженером — 95% та 80% відповідно. Крім того, архітектурний аудит (чиста архітектура, зв'язність) — це зона, де автоматика безсила: 0% виявлення. Наші інженери з 10+ роками досвіду бачать патерни, які не описати правилами.

Хочете таку ж детальну перевірку? Замовте консультацію.

Як ми знаходимо race conditions, які пропускають статичні аналізатори?

Використовуємо комбінацію інструментів: Thread Sanitizer (iOS) та Kotlin Flow перевірки. Але головне — ручний аналіз сценаріїв конкурентного доступу. Наприклад, на одному проекті ми знайшли race condition, коли фоновий потік оновлював дані для UI, а інший потік у цей же час читав їх — статичний аналіз мовчав. Ми виявили це, переглядаючи ланцюжки корутин та стан shared mutable state.

Як ми будуємо архітектурне рев'ю?

Дивимося на зв'язність компонентів: ViewModel напряму звертається до Context? Use case знає про шар представлення? Repository імпортує android.view.*? Це порушення Clean Architecture, які роблять код нетестованим та крихким. Для Flutter: перевіряємо, чи немає бізнес-логіки в StatefulWidget.build — вона має бути в Bloc/Cubit/ViewModel. Прямі виклики setState з API-запитами всередині — ознака архітектурного боргу. У React Native звертаємо увагу на неправильне використання hooks (наприклад, виклик setState в useEffect без залежностей).

Які вразливості ми шукаємо?

• Токени в UserDefaults / SharedPreferences plaintext
• Логування чутливих даних через print / Log.d — у release-збірці логи видно через adb logcat
• SQL-запити через конкатенацію рядків замість prepared statements (Room не дозволяє це зробити випадково, але прямі SQLiteDatabase-виклики — можуть)
• Deeplink handling без валідації параметрів — open redirect або injection через кастомну схему

Ми також перевіряємо використання ATS (App Transport Security) на iOS та Network Security Config на Android, щоб переконатися, що всі з'єднання захищені.

В одному з проектів після автоматичного аналізу команда пропустила 30% витоків пам'яті. Ми знайшли 45 критичних проблем, включаючи retain cycle в таймері, який не дозволяв звільнити екран чату. Після виправлення кількість кешів знизилась на 70%.

Процес та формат рев'ю

По кожному знайденому патерну — конкретний файл, рядок, пояснення чому це проблема та приклад виправлення. Жодних «слід розглянути рефакторинг» — або це баг/ризик з пріоритетом, або незначна рекомендація.

Що ви отримуєте за підсумками

• Детальний звіт: PDF з 20–50 сторінками опису кожного багу, його пріоритетом, файлом та рядком, а також готовим кодом виправлення.
• Доступ до інструментів: посилання на статичні аналізатори, які ми використовували, та їх конфігурації.
• Консультація: 60-хвилинний дзвінок з розробником, відповідальним за рев'ю, для розбору складних моментів.
• Підтримка: ми відповідаємо на питання щодо звіту протягом тижня після здачі.

Отримайте консультацію інженера до початку рев'ю — це безкоштовно. Зв'яжіться з нами, щоб обговорити ваш проект. Терміни рев'ю: від 2 до 5 днів залежно від обсягу. Ціна розраховується індивідуально, виходячи з кількості файлів та складності. Досвід наших інженерів — 10+ років у мобільній розробці, включаючи роботу з застосунками з мільйонною аудиторією. Замовте аудит мобільного коду під ключ, щоб виявити приховані проблеми до того, як вони потраплять у продакшн.

Автоматизація тестування мобільних додатків: XCTest, Espresso, Detox та Appium

Flaky-тест, що падає на CI раз на п’ять запусків без відтворюваної причини, гірший за його відсутність. Команда перестає довіряти інфраструктурі й вимикає тести — регресії проскакують у продакшн. Ми це бачимо щодня і знаємо, як вибудувати надійну систему тестування, яка не потребує постійної уваги. Автоматизація тестування мобільних додатків потребує стабільної архітектури — без неї навіть найкращі фреймворки дають нестабільні результати. Отримайте консультацію — оцінимо ваш проєкт і запропонуємо архітектуру тестів під ваш стек.

Чому flaky-тести небезпечні?

Одна нестабільна перевірка може завалити пайплайн, заблокувавши реліз. Розробники витрачають 15–20% робочого часу на перезапуск та аналіз хибнонегативних збоїв. Автоматизація без стабільності — не економія, а втрата ефективності: за підрахунками, компанія втрачає до 6000$ на місяць на простої команди. Ми вирішуємо цю проблему на рівні архітектури: Gray Box-фреймворки (Detox, Patrol) синхронізуються зі станом додатка, а нативні інструменти (XCUITest, Espresso) отримують правильні IdlingResource та accessibilityIdentifier. Результат: стабільність >99.5% на CI — це в 3 рази краще за середній показник по ринку. Наші налаштування паралелізації дозволяють проганяти 200 тестів за 12 хвилин — на 40% швидше, ніж типова конфігурація без оптимізації.

Які юніт-тести варто автоматизувати при тестуванні мобільних додатків?

На iOS XCTest — основа. Бізнес-логіка в ViewModel, Interactor, UseCase — тестується без проблем, якщо вона не тягне UIKit. Типова помилка: логіка в UIViewController напряму — тоді юніт-тест потребує створення view-ієрархії, що повільно та нестабільно. Вихід — виносити логіку в сервіси з @testable import.

Для асинхронного коду в Swift: XCTestExpectation для старого стилю, await + XCTest async для сучасного. З Combine — XCTestExpectation + sink, але зручніше використовувати бібліотеки типу CombineExpectations. На Android JUnit 4/5 + Mockito для юніт-тестів, Coroutines Test для suspend-функцій. runTest {} з kotlinx-coroutines-test — стандарт для ViewModel з StateFlow. Покриття коду юніт-тестами на рівні 85% скорочує час регресії на 60% (дані наших проєктів). Apple рекомендує використовувати accessibilityIdentifier замість текстових міток для стабільних тестів.

Чому стабільність UI-тестів важливіша за покриття?

XCUITest (iOS) та Espresso (Android) — нативні UI-тести. Працюють швидко, інтегровані з IDE, але тестують одну платформу. Головна проблема XCUITest — крихкість селекторів. app.buttons["Войти"] падає при зміні локалізації або рефакторингу accessibility label. Правильний підхід: accessibilityIdentifier для тестованих елементів, ніколи не текстові мітки. Ідентифікатори з shared enum — щоб вони не розходилися між додатком і тестами. Досвід показує: така практика знижує flakiness на 90%.

Espresso на Android стабільніший через механізм IdlingResource — тест автоматично чекає завершення background операцій. Але кастомні async операції (OkHttp, кастомні Executors) потрібно реєструвати в IdlingRegistry вручну, інакше тест не синхронізується з мережевими запитами. Ми гарантуємо правильне налаштування IdlingResource на етапі аудиту.

Приклад налаштування IdlingResource для OkHttp на Android:

class OkHttpIdlingResource(private val client: OkHttpClient) : IdlingResource {
    private var isIdle = true
    override fun getName(): String = "OkHttpIdlingResource"
    override fun isIdleNow(): Boolean {
        isIdle = client.dispatcher.runningCallsCount() == 0
        return isIdle
    }
    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {}
}
// Реєстрація в тестовому підготовчому коді:
IdlingRegistry.getInstance().register(OkHttpIdlingResource(okHttpClient))

Detox та Patrol: end-to-end для React Native та Flutter

Detox — E2E фреймворк для React Native, розроблений Wix. Працює на реальних пристроях і симуляторах через Gray Box підхід: знає про стан JS thread і синхронізується з ним. Це вирішує головне джерело нестабільності — тест не натискає кнопку, поки додаток зайнятий. Налаштування Detox нетривіальне. Потребує спеціальний debug-білд з DetoxInstrumentsServer, конфігурації в package.json і окремого Appium-сервера не потрібно. Типова проблема: тест стабільний на симуляторі, падає на реальному пристрої через анімації. Рішення — animations: disabled в Detox конфігурації для E2E білда.

Patrol — аналог для Flutter. Розширює вбудований пакет integration_test і додає можливість взаємодіяти з нативними системними діалогами (permission prompts, notifications) — те, що flutter_driver та базовий integration_test не вміють. Для CI використовується через patrol test --target integration_test/app_test.dart.

Appium: кроссплатформа з ціною

Appium — коли потрібно покрити iOS та Android одними тестами. Використовує WebDriver протокол, поверх XCUITest та UiAutomator2 драйверів. Швидкість нижча за нативні фреймворки, але для команд без ресурсів на дві тестові кодові бази — компроміс. Appium 2.x з плагінною архітектурою помітно зручніший за першу версію. appium-doctor діагностує оточення — корисний при налаштуванні CI.

CI та паралелізація: як пришвидшити прогін

Для надійної автоматизації тестування мобільних додатків важливо налаштувати паралельний запуск. Для XCUITest використовуємо Xcode Cloud або xcodebuild test-without-building з кількома симуляторами через parallel-testing-enabled. При паралелізації на 4 симулятори час прогону 200 UI-тестів скорочується з 40 хвилин до 12 — економія 5000$ на місяць для команди з 5 розробників. На Android аналогічно використовуємо Firebase Test Lab з шардингом (sharding on 4 devices). Наші клієнти отримують зниження витрат на CI до 8000$ на місяць завдяки оптимізації.

Типові помилки налаштування тестів

Як ми це робимо: процес роботи

1. Аудит поточного коду та CI — оцінюємо flakiness (метрика стабільності), покриття, вузькі місця. Використовуємо Allure для збору звітів і Xcode Report для iOS.
2. Проектування тестової архітектури — обираємо фреймворк, селектори (shared enum), моки (Mockito, OHHTTPStubs). Визначаємо шари: unit → UI → E2E.
3. Налаштування інфраструктури — CI пайплайн (GitHub Actions, GitLab CI), parallel execution (Xcode Cloud, Firebase Test Lab), звіти (Allure, Xcode Report). Додаємо метрики: час прогону, кількість flaky-тестів.
4. Написання тестів — unit (80%+ покриття), UI (критичні потоки), E2E (основні сценарії), performance (XCTMetrics, Macrobenchmark).
5. Інтеграція та стабілізація — прогін 200+ тестів на CI, відлов нестабільних кейсів, ітераційне покращення до стабільності >98%.
6. Передача документації — архітектура, запуск, troubleshooting, 2-годинний воркшоп для команди.

Що входить в роботу (deliverables)

• Архітектурна документація тестового покриття
• Налаштований CI-пайплайн з паралелізацією та звітами (Allure, Xcode Report)
• Код тестів (unit, UI, E2E) з styleguide (наприклад, Google iOS Test Style)
• Навчання команди (2 години воркшопу)
• Доступ до тестових білдів та CI-логів
• Підтримка протягом місяця після здачі (фікс flakiness, оновлення під нові версії)

Терміни орієнтовно

Налаштування інфраструктури з нуля (CI, unit + UI тести, звіти) — 2–3 тижні. Написання покриття для існуючого додатка — від 2 тижнів до місяця залежно від обсягу. Оцінимо ваш проєкт за 2 дні — зв’яжіться з нами. 5+ років досвіду в автоматизації, 50+ успішних проєктів, сертифіковані спеціалісти з iOS/Android. Гарантуємо стабільність тестів >98% на CI після впровадження. Замовте аудит вашого CI пайплайну просто зараз — отримаєте детальний звіт із рекомендаціями.