Code Coverage в мобильной разработке: что это, метрики и как измерять

Что такое Code Coverage

Code Coverage (покрытие кода) — это количественная метрика, которая определяет, какая часть исходного кода приложения была выполнена во время прохождения тестов. Она выражается в процентах и рассчитывается как отношение количества выполненных строк/веток к общему количеству. Высокое покрытие не гарантирует отсутствие багов, но снижает риск пропущенных ошибок.

Зачем измерять покрытие

Покрытие кода помогает команде: находить непротестированные участки кода, принимать решения о приоритетах написания тестов, отслеживать динамику качества тестирования в CI/CD. В мобильной разработке покрытие особенно важно для бизнес-логики, моделей данных и репозиториев — слоёв, где вероятность ошибок наиболее высока.

Мифы о Code Coverage

Распространённый миф: «100% покрытие = идеальное качество». На практике 100% покрытие достигается крайне редко и часто ценой поверхностных тестов. Эффективное покрытие — это не гонка за процентом, а стратегическое покрытие критических путей и граничных условий. Покрытие ничего не говорит о качестве самих тестов: тест может проходить, но не проверять корректность результата.

Метрики покрытия кода

Существует несколько метрик Code Coverage, каждая из которых измеряет разные аспекты тестирования. Line coverage (покрытие строк) — самая простая метрика, показывающая процент выполненных строк кода. Branch coverage (покрытие веток) измеряет, какие ветвления if-else и switch были протестированы.

Линейное покрытие (Line Coverage)

Line coverage считает каждую строку исходного кода выполненной или нет. Если в строке находится условный оператор или цикл, строка считается выполненной, если управление дошло до неё, даже если не все ветки обработаны. Это наименее строгая метрика, но самая понятная для визуальной оценки.

Покрытие веток (Branch Coverage)

Branch coverage оценивает, были ли протестированы все возможные ветвления в коде. Для каждого if-else учитываются обе ветки: true и false. Для switch — каждый case. Branch coverage считается более строгой метрикой, чем line coverage, и чаще выявляет непроверенные сценарии.

Покрытие путей (Path Coverage)

Path coverage — самая строгая метрика, требующая проверки всех возможных комбинаций ветвлений в функции. На практике path coverage редко используется из-за экспоненциального роста числа комбинаций: функция с 10 ветвлениями имеет 1024 возможных пути.

Инструменты для измерения покрытия

В мобильной разработке используются различные инструменты для измерения Code Coverage в зависимости от платформы. Для Android стандартом является JaCoCo (Java Code Coverage), который интегрируется с Gradle и поддерживает как юнит-тесты, так и инструментационные тесты. Для iOS используется XCCov, встроенный в Xcode.

JaCoCo для Android

JaCoCo генерирует отчёты в форматах HTML, XML и CSV. HTML-отчёт визуально подсвечивает строки: зелёные — выполненные, красные — пропущенные, жёлтые — частично выполненные. XML-отчёт совместим с SonarQube и другими системами анализа кода. JaCoCo поддерживает фильтрацию классов: можно исключить generated-код, databinding, BuildConfig.

// build.gradle — настройка JaCoCo
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// Создание отчёта JaCoCo
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

XCCov для iOS

XCCov — встроенный инструмент Xcode для измерения покрытия кода. Он включается через Gather coverage data в схеме тестирования. XCCov поддерживает покрытие для Swift и Objective-C, генерирует отчёты в .xccovreport и интегрируется с CI через xcodebuild -enableCodeCoverage YES. Данные выводятся в консоль и могут быть экспортированы в JSON.

SonarQube и Codecov

Для централизованного мониторинга покрытия используются платформы: SonarQube (анализ качества кода + покрытие), Codecov и Coveralls. Эти сервисы агрегируют данные из JaCoCo и XCCov, показывают тренды, Quality Gate и интеграцию с GitHub/GitLab через PR-комментарии.

Как улучшить покрытие кода

Повышение Code Coverage требует системного подхода: не «добивать проценты», а закрывать риски. Первым шагом анализируется отчёт JaCoCo или XCCov — выявляются красные (непокрытые) классы. Приоритет: бизнес-логика → репозитории → ViewModel → UI-компоненты.

Стратегия TDD

Test-Driven Development (TDD) автоматически обеспечивает высокое покрытие, поскольку тесты пишутся до реализации. Процесс: красный (написать падающий тест) → зелёный (написать минимальный код) → рефакторинг. TDD дисциплинирует разработчика, заставляя покрывать граничные случаи и исключительные ситуации, которые часто остаются без тестов.

Параметризованные тесты

Один параметризованный тест заменяет десятки обычных. JUnit и XCTest поддерживают параметризацию: @ParameterizedTest в JUnit 5, XCTestCase с testPerformanceExample в XCTest. Параметризация позволяет проверить множество входных данных без дублирования кода, что значительно расширяет покрытие веток и условий.

// Параметризованный тест на Kotlin с JUnit 5
@ParameterizedTest
@ValueSource(strings = ["user@test.com", "admin@test.com", "test@example.com"])
fun `validate email returns true for valid addresses`(email: String) {
    val result = EmailValidator.isValid(email)
    Assertions.assertTrue(result)
}

Ошибки при работе с Code Coverage

Наиболее частая ошибка — погоня за процентом без анализа качества тестов. Команда начинает писать тесты ради тестов: проверяет геттеры и сеттеры, дублирует покрытие на разных уровнях, тестирует тривиальные методы. Это даёт высокий процент, но не повышает реальное качество.

Ложное чувство безопасности

Высокий Code Coverage может создать ложное ощущение, что приложение хорошо протестировано. Тест может выполнить строку кода, но не проверить корректность результата. Например: тест вызывает метод расчёта скидки, но не проверяет сумму — строка выполнена, покрытие растёт, а баг не найден.

Игнорирование граничных случаев

Типичная ошибка — тестировать только «счастливый путь» (happy path) и игнорировать граничные случаи: пустые списки, null-значения, максимальные числа, некорректные форматы. Именно на границах и в исключениях возникает большинство багов. Branch coverage помогает выявить пропущенные ветки, но не гарантирует проверки граничных значений.

Mutation Testing — проверка качества тестов

Mutation Testing — это метод оценки качества тестов, при котором в исходный код вносятся мутации (искусственные ошибки) и проверяется, упадут ли тесты. Pitest — популярный инструмент mutation testing для Java и Kotlin. Если тесты не упали на мутации — значит, они не проверяют данное условие.

Принцип работы Pitest

Pitest создаёт мутантов — изменённые копии исходного кода, где, например, > заменено на >=, true на false, или удалён вызов метода. Затем для каждого мутанта запускаются тесты. Если тесты проходят — мутант выжил, значит, тесты не покрывают этот сценарий. Если тесты падают — мутант убит, тест корректный.

// build.gradle — настройка Pitest
plugins {
    id 'info.solidsoft.pitest' version '1.15.0'
}

pitest {
    targetClasses = ['com.example.app.*']
    targetTests = ['com.example.app.*Test']
    threads = 4
    outputFormats = ['HTML', 'XML']
    mutationThreshold = 80
    coverageThreshold = 85
}

Типы мутаций

Pitest поддерживает множество типов мутаций: изменение условных операторов (== → !=, < → <=), удаление вызовов методов, замена возвращаемых значений (true → false), изменение арифметических операций (+ → -), мутация инкрементов (i++ → i--). Чем больше типов мутаций убито тестами, тем надёжнее тестовый набор.

Mutation Score Goal

Целевой mutation score — 80% и выше. Это означает, что 80% искусственных ошибок обнаружены тестами. Покрытие кода (Code Coverage) в 90% не гарантирует, что тесты находят ошибки — mutation testing даёт более объективную оценку. Pitest может быть интегрирован в CI как Quality Gate, блокируя сборку при падении mutation score ниже порога.

Интеграция Code Coverage в CI/CD

Для автоматического контроля Code Coverage в CI/CD используются Quality Gates — пороговые значения, при нарушении которых сборка помечается как нестабильная или отклоняется. SonarQube позволяет настроить Quality Gate на основе комбинации метрик: покрытие (≥80%), количество багов, уязвимостей и дублированного кода.

Настройка Quality Gate в GitHub Actions

В GitHub Actions Code Coverage интегрируется через action-шаги: запуск тестов с покрытием → загрузка отчёта в Codecov → проверка порога. Codecov автоматически комментирует PR с диффом покрытия, показывая, какие строки изменились и как это повлияло на общий процент. Если покрытие упало — PR блокируется до написания дополнительных тестов.

# GitHub Actions — загрузка покрытия в Codecov
- name: Run Tests with Coverage
  run: ./gradlew testDebugUnitTest jacocoTestReport

- name: Upload to Codecov
  uses: codecov/codecov-action@v4
  with:
    files: ./app/build/reports/jacoco/jacocoTestReport.xml
    flags: unittests
    fail_ci_if_error: true

- name: Check Coverage Threshold
  run: |
    coverage=$(grep -oP 'branchCoverage="\K[0-9.]+' report.xml)
    if (( $(echo "$coverage < 80" | bc -l) )); then
      echo "Coverage $coverage% is below 80% threshold"
      exit 1
    fi

Отчётность и визуализация

HTML-отчёты JaCoCo и XCCov содержат визуальную подсветку покрытия: зелёный — выполненные строки, красный — невыполненные. SonarQube дополнительно показывает покрытие на уровне файла, класса, метода и строки, а также историю изменения покрытия по спринтам. Это помогает принимать решения о рефакторинге и добавлении тестов.