Code Coverage sa mobile development: ano ito, metrics at paano sukatin

Ano ang Code Coverage

Code Coverage (saklaw ng code) ay isang kwantitatibong metric na tumutukoy kung anong bahagi ng source code ng application ang naisagawa sa panahon ng mga test. Ito ay ipinapahayag sa porsyento at kinakalkula bilang ratio ng bilang ng mga linyang/sangay na naisagawa sa kabuuang bilang. Ang mataas na saklaw ay hindi ginagarantiyang walang mga bug, ngunit binabawasan ang panganib ng mga hindi napapansing pagkakamali.

Bakit sukatin ang saklaw

Ang saklaw ng code ay tumutulong sa koponan: mahanap ang hindi pa nasusubok na mga bahagi ng code, gumawa ng mga desisyon tungkol sa priyoridad ng pagsulat ng mga test, subaybayan ang dinamika ng kalidad ng pagsubok sa CI/CD. Sa mobile development, ang saklaw ay lalong mahalaga para sa business logic, data models at repositories — mga layer kung saan ang posibilidad ng pagkakamali ay pinakamataas.

Mga alamat tungkol sa Code Coverage

Isang karaniwang alamat: “100% saklaw = perpektong kalidad”. Sa praktika, ang 100% saklaw ay napakabihirang makamit at kadalasan sa halaga ng mababaw na mga test. Epektibong saklaw — hindi ito karera para sa porsyento, kundi estratehikong saklaw ng mga kritikal na landas at hangganang kondisyon. Ang saklaw ay walang sinasabi tungkol sa kalidad ng mga test mismo: ang isang test ay maaaring pumasa ngunit hindi suriin ang kawastuhan ng resulta.

Metrics ng saklaw ng code

Mayroong ilang mga metric ng Code Coverage, bawat isa ay sumusukat ng iba’t ibang aspeto ng pagsubok. Line coverage (saklaw ng linya) — ang pinakasimpleng metric na nagpapakita ng porsyento ng mga naisagawang linya ng code. Branch coverage (saklaw ng sangay) ay sumusukat kung aling mga sangay ng if-else at switch ang nasubukan.

Saklaw ng Linya (Line Coverage)

Ang Line coverage ay nagbibilang ng bawat linya ng source code bilang naisagawa o hindi. Kung sa isang linya ay may kondisyonal na operator o loop, ang linya ay itinuturing na naisagawa kung ang kontrol ay umabot dito, kahit na hindi lahat ng sangay ay naproseso. Ito ang pinaka hindi mahigpit na metric, ngunit pinaka-naiintindihan para sa biswal na pagsusuri.

Saklaw ng Sangay (Branch Coverage)

Ang Branch coverage ay sinusuri kung ang lahat ng posibleng mga sangay sa code ay nasubukan. Para sa bawat if-else, parehong sangay ay isinasaalang-alang: true at false. Para sa switch — bawat case. Ang Branch coverage ay itinuturing na mas mahigpit na metric kaysa sa line coverage at mas madalas na nakakatuklas ng mga hindi nasusubok na senaryo.

Saklaw ng Landas (Path Coverage)

Path coverage — ang pinakamahigpit na metric na nangangailangan ng pagsusuri ng lahat ng posibleng kombinasyon ng mga sangay sa isang function. Sa praktika, ang path coverage ay bihirang ginagamit dahil sa eksponensyal na paglaki ng bilang ng mga kombinasyon: ang isang function na may 10 sangay ay may 1024 posibleng landas.

Mga kasangkapan sa pagsukat ng saklaw

Sa mobile development, iba’t ibang kasangkapan ang ginagamit para sa pagsukat ng Code Coverage depende sa platform. Para sa Android, ang pamantayan ay JaCoCo (Java Code Coverage), na nagsasama sa Gradle at sumusuporta sa parehong unit test at instrumental na test. Para sa iOS, ginagamit ang XCCov, na naka-embed sa Xcode.

JaCoCo para sa Android

Ang JaCoCo ay lumilikha ng mga ulat sa HTML, XML at CSV na format. Ang ulat sa HTML ay biswal na nagha-highlight ng mga linya: berde — naisagawa, pula — nalaktawan, dilaw — bahagyang naisagawa. Ang ulat sa XML ay tugma sa SonarQube at iba pang sistema ng pagsusuri ng code. Sinusuportahan ng JaCoCo ang pag-filter ng mga klase: ang generated na code, databinding, BuildConfig ay maaaring ibukod.

// build.gradle — pagsasaayos ng JaCoCo
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// Paglikha ng ulat ng JaCoCo
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

XCCov para sa iOS

Ang XCCov — ay ang built-in na kasangkapan ng Xcode para sa pagsukat ng saklaw ng code. Ito ay naisaaktibo sa pamamagitan ng Gather coverage data sa scheme ng pagsubok. Sinusuportahan ng XCCov ang saklaw para sa Swift at Objective-C, lumilikha ng mga ulat sa .xccovreport at nagsasama sa CI sa pamamagitan ng xcodebuild -enableCodeCoverage YES. Ang data ay ipinapakita sa console at maaaring i-export sa JSON.

SonarQube at Codecov

Para sa sentralisadong pagsubaybay ng saklaw, ginagamit ang mga platform: SonarQube (pagsusuri ng kalidad ng code + saklaw), Codecov at Coveralls. Ang mga serbisyong ito ay nagtitipon ng data mula sa JaCoCo at XCCov, nagpapakita ng mga trend, Quality Gate at integrasyon sa GitHub/GitLab sa pamamagitan ng mga komento sa PR.

Paano pagbutihin ang saklaw ng code

Ang pagtaas ng Code Coverage ay nangangailangan ng sistematikong approach: hindi “habulin ang porsyento”, kundi takpan ang mga panganib. Ang unang hakbang ay suriin ang ulat ng JaCoCo o XCCov — tukuyin ang mga pulang (hindi nasasaklaw) na klase. Priyoridad: business logic → repositories → ViewModel → mga komponent ng UI.

Estratehiya ng TDD

Ang Test-Driven Development (TDD) ay awtomatikong tinitiyak ang mataas na saklaw, dahil ang mga test ay isinusulat bago ang implementasyon. Proseso: pula (sumulat ng test na nabigo) → berde (sumulat ng minimal na code) → refactoring. TDD ay nagdidisiplina sa developer, pinipilit na saklawin ang mga hangganang kaso at pambihirang sitwasyon na madalas ay walang test.

Mga Parameterized na Test

Isang parameterized na test ay pumapalit sa dose-dosenang ordinaryong test. Sinusuportahan ng JUnit at XCTest ang parametrisasyon: @ParameterizedTest sa JUnit 5, XCTestCase na may testPerformanceExample sa XCTest. Ang parametrisasyon ay nagpapahintulot na suriin ang maraming input data nang hindi inuulit ang code, na makabuluhang nagpapalawak ng saklaw ng mga sangay at kondisyon.

// Parameterized na test sa Kotlin na may 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)
}

Mga pagkakamali sa paggamit ng Code Coverage

Ang pinakakaraniwang pagkakamali — paghahabol sa porsyento nang hindi sinusuri ang kalidad ng mga test. Ang koponan ay nagsisimulang sumulat ng test para sa test: sinusuri ang mga getter at setter, inuulit ang saklaw sa iba’t ibang antas, sinusubukan ang mga trivial na method. Nagbibigay ito ng mataas na porsyento ngunit hindi nagpapataas ng tunay na kalidad.

Maling Pakiramdam ng Seguridad

Ang mataas na Code Coverage ay maaaring lumikha ng maling impresyon na ang application ay mahusay na nasubukan. Ang isang test ay maaaring magsagawa ng linya ng code ngunit hindi suriin ang kawastuhan ng resulta. Halimbawa: ang test ay tumatawag ng method para sa pagkalkula ng diskwento, ngunit hindi sinusuri ang halaga — ang linya ay naisagawa, ang saklaw ay tumaas, ngunit ang bug ay hindi natagpuan.

Pagpapabaya sa mga Hangganang Kaso

Karaniwang pagkakamali — subukan lamang ang “masayang landas” (happy path) at huwag pansinin ang mga hangganang kaso: mga walang laman na listahan, null na halaga, pinakamataas na numero, hindi tamang format. Karamihan sa mga bug ay nangyayari mismo sa mga hangganan at pagbubukod. Ang Branch coverage ay tumutulong na matukoy ang mga nalaktawang sangay, ngunit hindi ginagarantiyang susuriin ang mga hangganang halaga.

Mutation Testing — pagsusuri ng kalidad ng test

Ang Mutation Testing ay isang paraan ng pagsusuri ng kalidad ng test kung saan ang mga mutasyon (artipisyal na pagkakamali) ay ipinapasok sa source code at sinusuri kung ang mga test ay mabibigo. Pitest — sikat na kasangkapan para sa mutation testing para sa Java at Kotlin. Kung ang mga test ay hindi nabigo sa mutasyon — nangangahulugang hindi nila sinusuri ang kondisyong iyon.

Prinsipyo ng Paggana ng Pitest

Ang Pitest ay lumilikha ng mga mutant — binagong kopya ng source code, kung saan, halimbawa, ang > ay pinalitan ng >=, true ng false, o ang tawag sa method ay tinanggal. Pagkatapos para sa bawat mutant, ang mga test ay pinapatakbo. Kung ang mga test ay pumasa — ang mutant ay nakaligtas, nangangahulugang hindi saklaw ng mga test ang senaryong ito. Kung ang mga test ay nabigo — ang mutant ay pinatay, ang test ay tama.

// build.gradle — pagsasaayos ng 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
}

Mga Uri ng Mutasyon

Sinusuportahan ng Pitest ang maraming uri ng mutasyon: pagbabago ng kondisyonal na operator (== → !=, < → <=), pagtanggal ng mga tawag sa method, pagpapalit ng mga ibinabalik na halaga (true → false), pagbabago ng aritmetikong operasyon (+ → -), mutasyon ng increment (i++ → i--). Kung mas maraming uri ng mutasyon ang pinatay ng mga test, mas maaasahan ang hanay ng test.

Target na Mutation Score

Ang target na mutation score — 80% at mas mataas. Ito ay nangangahulugang 80% ng mga artipisyal na pagkakamali ay natuklasan ng mga test. Ang saklaw ng code (Code Coverage) na 90% ay hindi ginagarantiyang ang mga test ay nakakatagpo ng mga pagkakamali — ang mutation testing ay nagbibigay ng mas obhetibong pagsusuri. Pitest ay maaaring isama sa CI bilang Quality Gate, na humaharang sa build kapag ang mutation score ay bumaba sa ibaba ng threshold.

Integrasyon ng Code Coverage sa CI/CD

Para sa awtomatikong kontrol ng Code Coverage sa CI/CD, ginagamit ang Quality Gates — mga halaga ng threshold, na kapag nilabag, ang build ay minamarkahan bilang hindi matatag o tinatanggihan. SonarQube ay nagpapahintulot na i-configure ang Quality Gate batay sa kombinasyon ng mga metrics: saklaw (≥80%), bilang ng mga bug, mga kahinaan at naka-duplicate na code.

Pag-configure ng Quality Gate sa GitHub Actions

Sa GitHub Actions, ang Code Coverage ay isinasama sa pamamagitan ng mga hakbang ng action: pagpapatakbo ng mga test na may saklaw → pag-upload ng ulat sa Codecov → pagsusuri ng threshold. Codecov ay awtomatikong nagkokomento sa PR na may diff ng saklaw, na nagpapakita kung aling mga linya ang nagbago at kung paano ito nakaapekto sa kabuuang porsyento. Kung ang saklaw ay bumaba — ang PR ay haharangin hanggang sa pagsulat ng karagdagang mga test.

# GitHub Actions — pag-upload ng saklaw sa 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

Pag-uulat at Visualisasyon

Ang mga ulat sa HTML ng JaCoCo at XCCov ay naglalaman ng biswal na pagha-highlight ng saklaw: berde — naisagawang mga linya, pula — hindi naisagawa. SonarQube ay nagpapakita rin ng saklaw sa antas ng file, klase, method at linya, pati na rin ang kasaysayan ng mga pagbabago sa saklaw bawat sprint. Ito ay tumutulong sa paggawa ng desisyon tungkol sa refactoring at pagdagdag ng mga test.