Mobil Geliştirmede Code Coverage: Nedir, Metrikler ve Nasıl Ölçülür

Code Coverage Nedir

Code Coverage (kod kapsamı), testler sırasında uygulamanın kaynak kodunun hangi bölümünün yürütüldüğünü belirleyen nicel bir metriktir. Yüzde olarak ifade edilir ve yürütülen satır/dalların toplama oranı olarak hesaplanır. Yüksek kapsam hata olmadığını garanti etmez, ancak gözden kaçan hata riskini azaltır.

Kapsam Neden Ölçülmeli

Kod kapsamı ekibe şunlarda yardımcı olur: kodun test edilmemiş alanlarını bulmak, test yazma öncelikleri hakkında kararlar almak ve CI/CD'de test kalitesi dinamiklerini izlemek. Mobil geliştirmede kapsam, özellikle iş mantığı, veri modelleri ve depolar — hata olasılığının en yüksek olduğu katmanlar — için önemlidir.

Code Coverage Hakkında Mitler

Yaygın bir mit: “%100 kapsam = mükemmel kalite”. Pratikte, %100 kapsam son derece nadirdir ve genellikle yüzeysel testler pahasına elde edilir. Etkili kapsam yüzde yarışı değil, kritik yolların ve sınır durumların stratejik olarak kapsanmasıdır. Kapsam, testlerin kalitesi hakkında hiçbir şey söylemez: bir test geçebilir ancak sonucun doğruluğunu doğrulamayabilir.

Kod Kapsamı Metrikleri

Her biri testlerin farklı yönlerini ölçen birkaç Code Coverage metriği vardır. Line coverage (satır kapsamı) en basit metriktir ve yürütülen kod satırlarının yüzdesini gösterir. Branch coverage (dal kapsamı), hangi if-else ve switch dallarının test edildiğini ölçer.

Satır Kapsamı (Line Coverage)

Line coverage, her kaynak kod satırını yürütülmüş veya değil olarak sayar. Bir satır koşullu bir operatör veya döngü içeriyorsa, tüm dallar işlenmemiş olsa bile, kontrol o satıra ulaştıysa satır yürütülmüş kabul edilir. Bu, en az katı metriktir, ancak görsel değerlendirme için en anlaşılır olanıdır.

Dal Kapsamı (Branch Coverage)

Branch coverage, koddaki tüm olası dalların test edilip edilmediğini değerlendirir. Her if-else için her iki dal da dikkate alınır: true ve false. Switch için, her case dikkate alınır. Branch coverage, line coverage'dan daha katı bir metrik olarak kabul edilir ve test edilmemiş senaryoları daha sık ortaya çıkarır.

Yol Kapsamı (Path Coverage)

Path coverage en katı metriktir ve bir fonksiyondaki tüm olası dal kombinasyonlarının doğrulanmasını gerektirir. Pratikte, path coverage kombinasyon sayısının üstel olarak artması nedeniyle nadiren kullanılır: 10 dallı bir fonksiyonun 1024 olası yolu vardır.

Kapsam Ölçme Araçları

Mobil geliştirmede, platforma bağlı olarak Code Coverage'ı ölçmek için çeşitli araçlar kullanılır. Android için standart, Gradle ile entegre olan ve hem birim testlerini hem de enstrümantasyon testlerini destekleyen JaCoCo'dur (Java Code Coverage). iOS için Xcode'a gömülü XCCov kullanılır.

Android için JaCoCo

JaCoCo, HTML, XML ve CSV formatlarında raporlar oluşturur. HTML raporu satırları görsel olarak vurgular: yeşil — yürütülmüş, kırmızı — atlanmış, sarı — kısmen yürütülmüş. XML raporu SonarQube ve diğer kod analiz sistemleriyle uyumludur. JaCoCo, sınıf filtrelemeyi destekler: oluşturulan kod, veri bağlama ve BuildConfig hariç tutulabilir.

// build.gradle — JaCoCo yapılandırması
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// JaCoCo raporu oluşturma
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

iOS için XCCov

XCCov, kod kapsamını ölçmek için Xcode'a gömülü bir araçtır. Test şemasındaki Gather coverage data aracılığıyla etkinleştirilir. XCCov, Swift ve Objective-C için kapsamı destekler, .xccovreport formatında raporlar oluşturur ve xcodebuild -enableCodeCoverage YES aracılığıyla CI ile entegre olur. Veriler konsola görüntülenir ve JSON olarak dışa aktarılabilir.

SonarQube ve Codecov

Merkezi kapsam izleme için SonarQube (kod kalite analizi + kapsam), Codecov ve Coveralls gibi platformlar kullanılır. Bu hizmetler JaCoCo ve XCCov'dan verileri toplar, eğilimleri, Kalite Geçidini ve PR yorumları aracılığıyla GitHub/GitLab entegrasyonunu gösterir.

Kod Kapsamı Nasıl İyileştirilir

Code Coverage'ı iyileştirmek sistematik bir yaklaşım gerektirir: “yüzdeleri artırmak” değil, riskleri kapatmak. İlk adım, JaCoCo veya XCCov raporunu analiz etmek — kırmızı (kapsanmayan) sınıfları belirlemektir. Öncelik: iş mantığı → depolar → ViewModel → UI bileşenleri.

TDD Stratejisi

Test Odaklı Geliştirme (TDD), testler uygulamadan önce yazıldığı için otomatik olarak yüksek kapsam sağlar. Süreç: kırmızı (başarısız olacak bir test yazmak) → yeşil (minimum kodu yazmak) → yeniden düzenleme. TDD geliştiriciyi disipline eder ve genellikle testsiz kalan sınır durumları ve istisnai durumları kapsamaya zorlar.

Parametreli Testler

Bir parametreli test, düzinelerce sıradan testin yerini alır. JUnit ve XCTest parametrelendirmeyi destekler: JUnit 5'te @ParameterizedTest, XCTest'te testPerformanceExample ile XCTestCase. Parametrelendirme, kod tekrarı olmadan birden çok giriş verisini doğrulamaya olanak tanır ve dal ile koşul kapsamını önemli ölçüde genişletir.

// Kotlin'de JUnit 5 ile parametreli test
@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 ile Çalışırken Yapılan Hatalar

En yaygın hata, test kalitesini analiz etmeden yüzdeyi kovalamaktır. Ekip, testler için testler yazmaya başlar: getter ve setter'ları kontrol etmek, farklı seviyelerde kapsamı tekrarlamak, önemsiz metotları test etmek. Bu yüksek bir yüzde verir ancak gerçek kaliteyi iyileştirmez.

Yanlış Güvenlik Hissi

Yüksek Code Coverage, uygulamanın iyi test edildiğine dair yanlış bir his yaratabilir. Bir test bir kod satırını yürütebilir ancak sonucun doğruluğunu doğrulamayabilir. Örneğin: bir test indirim hesaplama metodunu çağırır ancak tutarı kontrol etmez — satır yürütülür, kapsam artar, ancak hata bulunmaz.

Sınır Durumlarını Görmezden Gelme

Tipik bir hata, yalnızca “mutlu yol”u (happy path) test etmek ve sınır durumlarını (boş listeler, null değerler, maksimum sayılar, yanlış formatlar) görmezden gelmektir. Hataların çoğu sınırlarda ve istisnalarda meydana gelir. Branch coverage, kaçırılan dalları belirlemeye yardımcı olur ancak sınır değerlerinin doğrulanmasını garanti etmez.

Mutasyon Testi — Test Kalitesinin Doğrulanması

Mutasyon Testi, kaynak koda mutasyonlar (yapay hatalar) eklenerek testlerin başarısız olup olmadığını kontrol eden bir test kalitesi değerlendirme yöntemidir. Pitest, Java ve Kotlin için popüler bir mutasyon testi aracıdır. Testler bir mutasyonda başarısız olmazsa, bu koşulu doğrulamadıkları anlamına gelir.

Pitest'in Çalışma Prensibi

Pitest, mutantlar oluşturur — > yerine >=, true yerine false konulan veya bir metot çağrısının kaldırıldığı kaynak kodun değiştirilmiş kopyaları. Ardından her mutant için testler çalıştırılır. Testler geçerse — mutant hayatta kalmıştır, yani testler bu senaryoyu kapsamıyor demektir. Testler başarısız olursa — mutant öldürülmüştür, test geçerlidir.

// build.gradle — Pitest yapılandırması
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
}

Mutasyon Türleri

Pitest birçok mutasyon türünü destekler: koşullu operatörleri değiştirme (== → !=, < → <=), metot çağrılarını kaldırma, dönüş değerlerini değiştirme (true → false), aritmetik işlemleri değiştirme (+ → -), artırma mutasyonu (i++ → i--). Testler tarafından ne kadar çok mutasyon türü öldürülürse, test paketi o kadar güvenilir olur.

Mutasyon Skoru Hedefi

Hedef mutasyon skoru %80 ve üzeridir. Bu, yapay hataların %80'inin testler tarafından tespit edildiği anlamına gelir. %90 kod kapsamı (Code Coverage), testlerin hata bulduğunu garanti etmez — mutasyon testi daha objektif bir değerlendirme sağlar. Pitest, CI'da Kalite Geçidi olarak entegre edilebilir ve mutasyon skoru eşiğin altına düştüğünde derlemeyi engelleyebilir.

Code Coverage'ın CI/CD'ye Entegrasyonu

CI/CD'de Code Coverage'ın otomatik kontrolü için Kalite Geçitleri (Quality Gate) kullanılır — ihlal edildiğinde derlemeyi dengesiz olarak işaretleyen veya reddeden eşik değerleridir. SonarQube, metriklerin bir kombinasyonuna dayalı olarak bir Kalite Geçidi yapılandırmaya izin verir: kapsam (≥%80), hata sayısı, güvenlik açıkları ve yinelenen kod.

GitHub Actions'da Kalite Geçidi Ayarlama

GitHub Actions'da Code Coverage, eylem adımları aracılığıyla entegre edilir: kapsamla testleri çalıştır → raporu Codecov'a yükle → eşiği kontrol et. Codecov, otomatik olarak PR'lara kapsam farkıyla yorum yapar, hangi satırların değiştiğini ve bunun genel yüzdeyi nasıl etkilediğini gösterir. Kapsam düştüyse, ek testler yazılana kadar PR engellenir.

# GitHub Actions — Codecov'a kapsam yükleme
- 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

Raporlama ve Görselleştirme

JaCoCo ve XCCov'un HTML raporları görsel kapsam vurgulaması içerir: yeşil — yürütülen satırlar, kırmızı — yürütülmeyenler. SonarQube ayrıca dosya, sınıf, metot ve satır düzeyinde kapsamı ve sprintler boyunca kapsam değişikliği geçmişini gösterir. Bu, yeniden düzenleme ve test ekleme konusunda kararlar almaya yardımcı olur.