Аудит кодової бази мобільного застосунку: iOS, Android, Flutter

70% проектів із високим тестовим покриттям (80%+) стикаються з регресіями в бізнес-логіці — це статистика наших аудитів. Причина: тести покривають UI та геттери, а не Use Cases та ViewModels. Типова ситуація: ви додаєте нову фічу, CI зелений, але після мерджа падає вже працюючий функціонал. Аудит кодової бази мобільного застосунку виявляє такі «сліпі зони» та показує, де реально потрібні тести. Наш досвід — понад 10 років у мобільній розробці та десятки виконаних аудитів — діагностує проблеми, які в 60% проектів залишаються прихованими до першого інциденту. Ми гарантуємо, що звіт міститиме actionable рекомендації, а не загальні фрази.

Як аудит кодової бази запобігає регресіям?

Код-рев'ю перевіряє окремий PR: стиль, логіку, баги. Аудит відповідає на питання: «чи можна з цим кодом жити наступні два-три роки, додавати фічі без постійних регресій, онбордити нових розробників за розумний час?» Це аналіз системного технічного боргу, а не точкових проблем. Циклічні залежності між модулями зустрічаються в 40% проектів, hardcoded API keys — у 30%. Без аудиту ці цифри залишаються прихованими до першого інциденту. Згідно з OWASP Mobile Security Testing Guide, подібні вразливості класифікуються як High Risk.

Що саме ми перевіряємо?

Архітектурна зв'язність. Дивимося на dependency graph: чи є циклічні залежності між модулями, чи порушені межі шарів, чи залежить UI від конкретних мережевих бібліотек напряму. Для iOS — перевіряємо розділення на feature modules або хоча б дотримання MVVM/VIPER у межах одного таргета. Для Android — Clean Architecture з Use Cases, або все звалено в Activity. Інструменти: Xcode Dependency Graph, Android Studio Module Dependencies, ArchUnit для автоматизованої перевірки.

Тестове покриття. Дивимося не лише відсоток, а й що саме покрито. 80% coverage на тривіальних геттерах і 10% на бізнес-логіці — гірше, ніж 30% правильних тестів на Use Cases та ViewModels. Перевіряємо наявність інтеграційних тестів (UI, XCUITest, Espresso), моків для мережевих залежностей, тестів на edge cases (порожній список, помилка мережі, таймаут). У 70% проектів тестове покриття бізнес-логіки не перевищує 20%, що призводить до регресій. Автоматизований аналіз у 3-5 разів скорочує час перевірки порівняно з ручним рев'ю.

Управління залежностями. CocoaPods vs SPM, Gradle catalogs, застарілі версії. Бібліотеки з відомими CVE — перевіряємо через OWASP Dependency-Check або знімок із pod outdated / ./gradlew dependencyUpdates. Особливо дивимося на бібліотеки, які запитують надлишкові дозволи (Analytics SDK, Ad SDK) — вони можуть порушувати App Store/Play Store privacy policies.

Продуктивність та витоки пам'яті. Статичний аналіз не замінює профілювальник, але в 90% випадків знаходить патерни: синхронні завдання на main thread, image створюється без кешування в циклі, URLSession створюється per-request замість синглтона. Для Flutter — const конструктори не використовуються там, де повинні, дорогі обчислення в build(). Середня частота витоків пам'яті у великих проектах — 3-5 на 1000 рядків коду.

Безпека. Автоматизований аналіз через MobSF (Mobile Security Framework) або Semgrep з мобільними правилами. Шукаємо: hardcoded API keys у коді або plist, логування чутливих даних, небезпечні IPC (exported Activities без permission), використання застарілих алгоритмів (MD5, SHA1 для критичних операцій). Також перевіряємо конфігурації Code Signing, provisioning profile, налаштування Push Notifications (APNs/FCM), deep linking (Universal Links / App Links) та ATT (App Tracking Transparency). Згідно з App Store Review Guidelines, user data must be handled with care — hardcoded credentials are a direct violation.

Які інструменти ми використовуємо?

SonarQube інтегрується в CI та рахує цикломатичну складність, дублювання коду, cognitive complexity. Функція з complexity > 15 — кандидат на рефакторинг, це не смаковщина, це вимірний ризик.

Чому автоматизовані інструменти не замінюють ручний аналіз?

Хоча інструменти на кшталт Periphery знаходять невикористаний код, а MobSF виявляє вразливості, лише ручний аудит архітектури дозволяє оцінити, як технічний борг вплине на майбутню розробку. В одному проекті ми виявили циклічну залежність, яка збільшувала час збірки на 40% — статичний аналізатор її не показав, тому що залежності були через reflection. Наш досвід запобігає таким ситуаціям.

Як ми проводимо аудит?

1. Збір метрик — статичний аналіз всього коду, dependency graph, тестове покриття.
2. Глибоке рев'ю архітектури — виявлення cyclic dependencies, violation of Clean Architecture.
3. Ручна перевірка безпеки — перегляд конфігурацій, маніфестів, plist.
4. Профілювання продуктивності — пошук витоків і вузьких місць.
5. Формування звіту — дорожня карта з оцінкою ризиків та пріоритетів.

Використання автоматизованих інструментів скорочує час аналізу в 3-5 разів порівняно з ручною перевіркою. Periphery для iOS знаходить невикористані функції, класи, протоколи. У великій кодовій базі накопичуються тисячі рядків мертвого коду, які читають, підтримують і бояться видалити.

Що ви отримуєте в результаті?

• Звіт із чотирма рівнями: Critical (негайне виправлення — витік даних, crasher), High (наступний спринт — архітектурний ризик, security issue), Medium (технічний борг, планується), Low (рекомендації щодо якості).
• Дорожня карта рефакторингу з оцінкою ризиків та пріоритетів — що рефакторити спочатку, що можна відкласти.
• Документація щодо виявлених проблем та рекомендації щодо їх усунення.
• Список застарілих залежностей із зазначенням CVE та версій для міграції.
• Рекомендації щодо покращення CI/CD для автоматизації контролю якості.

Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію щодо аудиту — оцінимо терміни та обсяг робіт індивідуально. Аудит без плану дій — безглуздий документ, тому ми завжди даємо actionable рекомендації.

Терміни — від 3 до 5 днів на проект середнього розміру (до 200k рядків). Великі проекти (300k+ рядків, декілька платформ) — до 2 тижнів. Точна вартість розраховується після ознайомлення з проектом. Економія бюджету на рефакторинг з нашими рекомендаціями може досягати 40% за рахунок пріоритизації критичних проблем.

Автоматизація тестування мобільних додатків: 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 пайплайну просто зараз — отримаєте детальний звіт із рекомендаціями.