Интеграция Shake SDK для баг-репортинга в iOS и Android приложениях

Вы получаете баг-репорт от пользователя: 'Приложение вылетает'. Без версии, без логов, без последовательности действий. Команда тратит часы на воспроизведение. Shake SDK решает эту проблему, автоматически собирая скриншот с аннотациями, логи консоли и сетевые запросы. Интеграция занимает один день, а экономия времени на отладку — до 40%. Мы помогаем с интеграцией Shake в ваше iOS/Android приложение, настраиваем кастомные метаданные и подключаем issue tracker. Свяжитесь с нами, чтобы получить оценку проекта за 1 день.

Как Shake улучшает процесс отладки?

Shake — альтернатива Instabug с акцентом на простоту интеграции и меньший SDK overhead (~300 КБ). Основное отличие: Shake делает акцент на визуальных аннотациях скриншота (стрелки, рамки, текст прямо на экране), что ускоряет коммуникацию между тестировщиком и разработчиком без длинных текстовых описаний. Дополнительно SDK перехватывает сетевые запросы (через OkHttp interceptor на Android) и логи консоли — вы получаете полную картину ошибки. Shake SDK documentation подтверждает, что сбор метаданных происходит без утечки конфиденциальных данных.

Интеграция

iOS:

import Shake

func application(_ application: UIApplication,
                 didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    Shake.start(apiKey: "YOUR_API_KEY")
    Shake.configuration.isNetworkRequestsEnabled = true
    Shake.configuration.isConsoleLogsEnabled = true
    return true
}

Android:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Shake.start(this, "YOUR_API_KEY")
        Shake.getReportConfiguration().isNetworkRequestsEnabled = true
    }
}

Shake перехватывает сетевые запросы через встроенный OkHttp interceptor — подключается автоматически, если OkHttp используется в проекте (через Retrofit или напрямую). Для нестандартных HTTP-клиентов — ручное логирование через Shake.networkRequestBuilder().

Что даёт Shake из коробки

• Gesture-based invocation: shake, long press, кастомный floating button
• Аннотирование скриншота: стрелки, рамки, blur (для скрытия чувствительных данных прямо в UI)
• Автоматические метаданные: device, OS, app version, locale, network type
• Activity history (последние N экранов)
• Лог консоли за последние X минут до репорта
• Поддержка Universal Links / App Links для deep linking

Дашборд Shake проще Instabug — меньше настроек, быстрее onboarding команды. Интеграции с Jira, Linear, Slack, Notion — до 10 инструментов.

Почему стоит выбрать Shake вместо аналогов?

Если команда небольшая и нужен базовый bug reporting без лишних зависимостей — Shake разумный выбор. При этом мы гарантируем стабильную работу SDK после интеграции. Наши инженеры имеют сертификаты и опыт более 5 лет в интеграции подобных SDK.

Кастомные метаданные

Полезно добавить контекст текущего пользователя:

Shake.setMetadata(key: "userId", value: currentUser.id)
Shake.setMetadata(key: "plan", value: currentUser.subscriptionPlan)
Shake.setMetadata(key: "environment", value: AppConfig.environment)

Тогда каждый репорт сразу покажет, под каким пользователем воспроизвелся баг — не нужно спрашивать тестировщика отдельно. Мы настраиваем эти метаданные под вашу бизнес-логику.

Что входит в работу

• Анализ текущей архитектуры приложения и выбор способа интеграции
• Интеграция SDK для iOS (Swift) и/или Android (Kotlin)
• Настройка кастомных метаданных и invocation gestures
• Интеграция с issue tracker (Jira, Linear, Asana) — по вашему выбору
• Тестирование на реальных устройствах и в TestFlight/Google Play
• Документация по эксплуатации и обучение команды
• Поддержка после деплоя в течение 2 недель

Процесс работы

Сроки и стоимость

Базовая интеграция — 1 день. Если нужны кастомные метаданные и интеграция с трекером — 2-3 дня. Стоимость рассчитывается индивидуально в зависимости от сложности и количества платформ. Оценим ваш проект за 1 день. Свяжитесь с нами, чтобы обсудить детали.

Наша команда имеет 5+ лет опыта в интеграции SDK для баг-репортинга и работала как с Shake, так и с Instabug, Firebase Crashlytics. Более 50 успешных проектов. Гарантируем качество и соблюдение сроков. Получите консультацию прямо сейчас.

Тестирование мобильных приложений: XCTest, Espresso, Detox и Appium

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

Почему flaky-тесты опасны?

Одна нестабильная проверка может завалить пайплайн, заблокировав релиз. Разработчики тратят 15-20% рабочего времени на перезапуск и анализ ложнонегативных сбоев. Автоматизация без стабильности — не экономия, а потеря эффективности. Мы решаем эту проблему на уровне архитектуры: Gray Box-фреймворки (Detox, Patrol) синхронизируются с состоянием приложения, а native инструменты (XCUITest, Espresso) получают правильные IdlingResource и accessibilityIdentifier. Результат: стабильность >99% на CI.

Unit-тесты: что тестировать, а что нет

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

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

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 на этапе аудита.

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

Detox — E2E фреймворк для React Native, разработанный Wix. Работает на реальных устройствах и симуляторах через Gray Box подход: знает о состоянии JS thread и синхронизируется с ним. Это решает главный flakiness-источник — тест не нажимает кнопку, пока приложение занято. Настройка 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. Время прогона 200 UI-тестов с параллелизацией на 4 симулятора — с 40 минут до 12. На Android аналогично используем Firebase Test Lab с шардингом.

Типичные ошибки при настройке (и как их избежать)

Как мы это делаем: процесс работы

1. Аудит текущего кода и CI — оцениваем flakiness, покрытие, узкие места.
2. Проектирование тестовой архитектуры — выбираем фреймворк, селекторы, моки.
3. Настройка инфраструктуры — CI пайплайн, parallel execution, отчёты (Allure, Xcode Report).
4. Написание тестов — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Интеграция и стабилизация — прогон 200+ тестов, отлов flaky-кейсов.
6. Передача документации — архитектура, запуск, troubleshooting.

Что входит в работу (deliverables)

• Архитектурная документация тестового покрытия
• Настроенный CI-пайплайн с параллелизацией и отчётами
• Код тестов (unit, UI, E2E) с styleguide
• Обучение команды (2 часа воркшопа)
• Доступ к тестовым билдам и CI-логам
• Поддержка в течение месяца после сдачи (фикс flakiness, обновление под новые версии)

Сроки ориентировочно

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