موبائل ڈیولپمنٹ میں 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 کے لیے Xcode میں شامل XCCov استعمال کیا جاتا ہے۔

Android کے لیے JaCoCo

JaCoCo HTML، XML اور CSV فارمیٹس میں رپورٹیں تیار کرتا ہے۔ HTML رپورٹ بصری طور پر لائنوں کو نمایاں کرتی ہے: سبز — عمل میں لائی گئی، سرخ — چھوڑی گئی، پیلا — جزوی طور پر عمل میں لائی گئی۔ XML رپورٹ SonarQube اور دیگر کوڈ تجزیہ نظاموں کے ساتھ مطابقت رکھتی ہے۔ JaCoCo کلاس فلٹرنگ کو سپورٹ کرتا ہے: تیار کردہ کوڈ، ڈیٹا بائنڈنگ اور BuildConfig کو خارج کیا جا سکتا ہے۔

// build.gradle — JaCoCo ترتیب
android {
    buildTypes {
        debug {
            testCoverageEnabled = true
        }
    }
}

// JaCoCo رپورٹ تیار کرنا
task jacocoTestReport(type: JacocoReport) {
    dependsOn 'testDebugUnitTest'
    reports {
        xml.enabled = true
        html.enabled = true
    }
}

iOS کے لیے XCCov

XCCov کوڈ کوریج ناپنے کے لیے Xcode میں شامل ایک آلہ ہے۔ یہ ٹیسٹ اسکیم میں Gather coverage data کے ذریعے فعال کیا جاتا ہے۔ XCCov Swift اور Objective-C کے لیے کوریج کو سپورٹ کرتا ہے، .xccovreport فارمیٹ میں رپورٹیں تیار کرتا ہے اور xcodebuild -enableCodeCoverage YES کے ذریعے CI کے ساتھ ضم ہوتا ہے۔ ڈیٹا کنسول پر دکھایا جاتا ہے اور JSON میں برآمد کیا جا سکتا ہے۔

SonarQube اور Codecov

مرکزی کوریج نگرانی کے لیے SonarQube (کوڈ کوالٹی تجزیہ + کوریج)، Codecov اور Coveralls جیسے پلیٹ فارم استعمال کیے جاتے ہیں۔ یہ خدمات JaCoCo اور XCCov سے ڈیٹا اکٹھا کرتی ہیں، رجحانات، کوالٹی گیٹ اور PR تبصروں کے ذریعے GitHub/GitLab کے ساتھ انضمام دکھاتی ہیں۔

کوڈ کوریج کو کیسے بہتر بنایا جائے

Code Coverage کو بہتر بنانے کے لیے ایک منظم طریقہ کار درکار ہے: “فیصد بڑھانا” نہیں، بلکہ خطرات کو بند کرنا۔ پہلا قدم JaCoCo یا XCCov رپورٹ کا تجزیہ کرنا ہے — سرخ (غیر کور) کلاسوں کی نشاندہی کرنا۔ ترجیح: کاروباری منطق → ذخیرے → ViewModel → UI اجزاء۔

TDD حکمت عملی

ٹیسٹ سے چلنے والی ترقی (TDD) خود بخود اعلی کوریج کو یقینی بناتی ہے، کیونکہ جانچیں عمل درآمد سے پہلے لکھی جاتی ہیں۔ عمل: سرخ (ناکام ہونے والی جانچ لکھنا) → سبز (کم سے کم کوڈ لکھنا) → ریفیکٹر۔ TDD ڈیویلپر کو نظم و ضبط دیتا ہے، انہیں حدی صورتوں اور غیر معمولی حالات کو کور کرنے پر مجبور کرتا ہے جو اکثر بغیر جانچ کے رہ جاتے ہیں۔

پیرامیٹرائزڈ ٹیسٹ

ایک پیرامیٹرائزڈ ٹیسٹ درجنوں عام جانچوں کی جگہ لے لیتا ہے۔ JUnit اور XCTest پیرامیٹرائزیشن کو سپورٹ کرتے ہیں: JUnit 5 میں @ParameterizedTest، XCTest میں testPerformanceExample کے ساتھ XCTestCase۔ پیرامیٹرائزیشن کوڈ کی تکرار کے بغیر متعدد ان پٹ ڈیٹا کی تصدیق کرنے کی اجازت دیتی ہے، جو برانچ اور شرط کی کوریج کو نمایاں طور پر بڑھاتا ہے۔

// 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 چھوٹی گئی شاخوں کی نشاندہی کرنے میں مدد کرتا ہے، لیکن حدی اقدار کی تصدیق کی ضمانت نہیں دیتا۔

میوٹیشن ٹیسٹنگ — جانچوں کے معیار کی تصدیق

میوٹیشن ٹیسٹنگ جانچوں کے معیار کا جائزہ لینے کا ایک طریقہ ہے جس میں سورس کوڈ میں میوٹیشنز (مصنوعی غلطیاں) ڈالی جاتی ہیں اور دیکھا جاتا ہے کہ جانچیں ناکام ہوتی ہیں یا نہیں۔ Pitest 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--)۔ جتنی زیادہ میوٹیشن اقسام جانچوں سے ماری جاتی ہیں، جانچ کا مجموعہ اتنا ہی زیادہ قابل بھروسہ ہوتا ہے۔

میوٹیشن سکور کا ہدف

ہدف میوٹیشن سکور 80% یا اس سے اوپر ہے۔ اس کا مطلب ہے کہ 80% مصنوعی غلطیاں جانچوں سے پکڑی جاتی ہیں۔ 90% کوڈ کوریج اس بات کی ضمانت نہیں دیتی کہ جانچیں بگ ڈھونڈتی ہیں — میوٹیشن ٹیسٹنگ زیادہ معروضی جائزہ فراہم کرتی ہے۔ Pitest کو CI میں کوالٹی گیٹ کے طور پر ضم کیا جا سکتا ہے، میوٹیشن سکور کے حد سے نیچے گرنے پر بلڈ کو مسدود کرتا ہے۔

CI/CD میں Code Coverage کا انضمام

CI/CD میں Code Coverage کے خودکار کنٹرول کے لیے کوالٹی گیٹ استعمال کیے جاتے ہیں — حدی اقدار جن کی خلاف ورزی پر بلڈ کو غیر مستحکم نشان زد کیا جاتا ہے یا مسترد کر دیا جاتا ہے۔ SonarQube میٹرکس کے امتزاج کی بنیاد پر کوالٹی گیٹ ترتیب دینے کی اجازت دیتا ہے: کوریج (≥80%)، بگ کی تعداد، کمزوریاں اور ڈپلیکیٹ کوڈ۔

GitHub Actions میں کوالٹی گیٹ ترتیب دینا

GitHub Actions میں، Code Coverage ایکشن مراحل کے ذریعے ضم کیا جاتا ہے: کوریج کے ساتھ ٹیسٹ چلائیں → رپورٹ Codecov پر اپ لوڈ کریں → حد چیک کریں۔ Codecov خود بخود PRs پر کوریج فرق کے ساتھ تبصرہ کرتا ہے، ظاہر کرتا ہے کہ کون سی لائنیں تبدیل ہوئیں اور اس نے مجموعی فیصد کو کیسے متاثر کیا۔ اگر کوریج کم ہوئی تو، اضافی ٹیسٹ لکھے جانے تک 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

رپورٹنگ اور تصور

JaCoCo اور XCCov کی HTML رپورٹوں میں بصری کوریج نمایاں کرنا شامل ہے: سبز — عمل میں لائی گئی لائنیں، سرخ — عمل میں نہ لائی گئی۔ SonarQube اضافی طور پر فائل، کلاس، طریقہ اور لائن کی سطح پر کوریج ظاہر کرتا ہے، نیز سپرنٹ کے اعتبار سے کوریج کی تبدیلی کی تاریخ بھی۔ یہ ریفیکٹرنگ اور ٹیسٹ شامل کرنے کے بارے میں فیصلے لینے میں مدد کرتا ہے۔