موبائل ڈویلپمنٹ میں یونٹ ٹیسٹنگ: یہ کیا ہے، طریقے اور فریم ورک

یونٹ ٹیسٹنگ کیا ہے؟

یونٹ ٹیسٹنگ سورس کوڈ کے انفرادی یونٹس — فنکشنز، میتھڈز، کلاسز — کو پروگرام کے باقی حصوں سے الگ کرکے تصدیق کرنے کا عمل ہے۔ ہر ٹیسٹ ماڈیول کے ایک مخصوص استعمال کے منظر نامے کو چلاتا ہے اور چیک کرتا ہے کہ نتیجہ متوقع سے مطابقت رکھتا ہے یا نہیں۔ یونٹ ٹیسٹ اسی پروگرامنگ زبان میں لکھے جاتے ہیں جس میں مرکزی کوڈ ہوتا ہے اور ڈویلپمنٹ ماحول یا CI/CD پائپ لائن میں خود بخود چلتے ہیں۔ انٹیگریشن ٹیسٹ کے برعکس، یونٹ ٹیسٹ حقیقی ڈیٹا بیس، فائل سسٹم یا نیٹ ورک سروسز کے ساتھ تعامل نہیں کرتے۔

یونٹ ٹیسٹ کیوں ضروری ہیں؟

بنیادی مقصد تبدیلیوں کے بعد کوڈ کی درستگی کے بارے میں فوری فیڈ بیک ہے۔ اگر کوئی ڈویلپر کسی میتھڈ کو ری فیکٹر کرتا ہے، تو یونٹ ٹیسٹ کا سیٹ تصدیق کرتا ہے کہ رویہ نہیں ٹوٹا۔ Google Testing Blog (2025) کے مطابق، 60% سے زیادہ یونٹ ٹیسٹ کوریج والے منصوبوں میں پروڈکشن واقعات 2.5 گنا کم ہوتے ہیں۔ اضافی فوائد: کوڈ دستاویزات (ٹیسٹ دکھاتے ہیں کہ API کیسے استعمال کریں)، ری فیکٹرنگ کو آسان بنانا (رویہ برقرار رکھتے ہوئے نفاذ تبدیل کیا جا سکتا ہے)، اور تیز رفتار ریگریشن تشخیص۔

یونٹ ٹیسٹ کیا سمجھا جاتا ہے؟

ہر خودکار ٹیسٹ یونٹ ٹیسٹ نہیں ہے۔ معیار: ایک ماڈیول (کلاس یا فنکشن) کا ٹیسٹ کیا جاتا ہے، بیرونی انحصار کو موک یا سٹب سے بدل دیا جاتا ہے، ٹیسٹ ملی سیکنڈ میں چلتا ہے، اور سرور یا ڈیٹا بیس شروع کرنے کی ضرورت نہیں ہوتی۔ حقیقی ڈیٹا بیس تک رسائی حاصل کرنے والا ٹیسٹ انٹیگریشن ٹیسٹ ہے۔ براؤزر کھولنے والا ٹیسٹ E2E ٹیسٹ ہے۔ ٹیسٹ کی اقسام کے درمیان حدود کو سمجھنا ٹیسٹ اہرام میں مناسب طریقے سے کوششیں تقسیم کرنے کے لیے اہم ہے۔

FIRST اصول اور AAA ڈھانچہ

معیاری یونٹ ٹیسٹ Robert C. Martin کے وضع کردہ FIRST اصولوں پر عمل کرتے ہیں۔ ہر ٹیسٹ Fast (تیز — ملی سیکنڈ)، Isolated (الگ — دوسرے ٹیسٹ پر منحصر نہیں)، Repeatable (دہرایا جا سکنے والا — کسی بھی مشین پر ایک جیسا نتیجہ)، Self-validating (خود تصدیق کرنے والا — نتیجہ "پاس" یا "فیل"، دستی جانچ کے بغیر)، اور Timely (بروقت — کوڈ سے پہلے یا ساتھ لکھا گیا) ہونا چاہیے۔ کسی بھی اصول کی خلاف ورزی ٹیسٹ کی قدر کم کر دیتی ہے۔

AAA ڈھانچہ (Arrange-Act-Assert)

یونٹ ٹیسٹ لکھنے کے لیے ایک معیاری سانچہ۔ Arrange — ڈیٹا اور انحصار کی تیاری: آبجیکٹ بنانا، موک کنفیگر کرنا، ان پٹ پیرامیٹرز سیٹ کرنا۔ Act — ٹیسٹ کی گئی کارروائی کو انجام دینا: میتھڈ یا فنکشن کو کال کرنا۔ Assert — نتیجے کی تصدیق: حقیقی قدر کا متوقع قدر سے موازنہ کرنا۔ تین بلاکس میں تقسیم ٹیسٹ کو پڑھنے اور سمجھنے میں آسان بناتا ہے۔ اگر Assert بلاک کو پیچیدہ منطق کی ضرورت ہو، تو ٹیسٹ ممکنہ طور پر ایک ساتھ بہت زیادہ چیک کر رہا ہے۔

// Kotlin میں JUnit 5 کے ساتھ AAA پیٹرن کا استعمال کرتے ہوئے یونٹ ٹیسٹ کی مثال
class CalculatorTest {

    private lateinit var calculator: Calculator

    @BeforeEach
    fun setUp() {
        // ARRANGE — ٹیسٹ آبجیکٹ بنائیں
        calculator = Calculator()
    }

    @Test
    fun addition_shouldReturnCorrectSum() {
        // ACT — کارروائی انجام دیں
        val result = calculator.add(2, 3)

        // ASSERT — نتیجہ کی تصدیق کریں
        Assertions.assertEquals(5, result)
    }
}

ٹیسٹ کا نام رکھنا

ٹیسٹ کے نام کو یہ بتانا چاہیے کہ کیا جانچا جا رہا ہے اور کیا نتیجہ متوقع ہے۔ فارمیٹ: [methodName]_[scenario]_[expectedResult]۔ مثال: calculateTotal_whenDiscountApplied_shouldReturnDiscountedTotal۔ ایک اچھا ٹیسٹ نام تبصرے کی جگہ لیتا ہے اور ناکام ہونے پر فوری طور پر بتاتا ہے کہ کون سی فعالیت ٹوٹی ہے۔ test1، checkSomething یا verify جیسے ناموں سے گریز کریں — یہ معلومات نہیں دیتے اور تشخیص کو پیچیدہ بناتے ہیں۔

موک، سٹب اور فیک: کیا اور کب استعمال کریں

جانچے گئے ماڈیول کو بیرونی انحصار سے الگ کرنے کے لیے ٹیسٹ ڈبل (test doubles) استعمال کیے جاتے ہیں۔ اہم اقسام: موک (mocks) — تصدیق کرتے ہیں کہ ایک مخصوص میتھڈ متوقع پیرامیٹرز کے ساتھ کال کیا گیا تھا؛ سٹب (stubs) — میتھڈ کال کرنے پر پہلے سے طے شدہ قدریں لوٹاتے ہیں؛ فیک (fakes) — حقیقی اجزاء کے آسان نفاذ (مثلاً، ڈیٹا بیس کے ساتھ کام کرنے والے UserRepository کے بجائے InMemoryUserRepository)۔ انتخاب اس بات پر منحصر ہے کہ کیا تصدیق کرنی ہے: حالت (سٹب) یا تعامل (موک)۔

Mockito: Java/Kotlin میں موکنگ کی مثال

Mockito Java اور Kotlin کے لیے سب سے مقبول موکنگ فریم ورک ہے۔ یہ mock() کے ذریعے موک بنانے، when().thenReturn() کے ذریعے واپسی کی قدروں کو کنفیگر کرنے اور verify() کے ذریعے کالز کی تصدیق کرنے کی اجازت دیتا ہے۔ Mockito (5.x) کے جدید ورژن سٹیٹک موک (mockStatic) اور BDDMockito (given-willReturn) کے ذریعے آسان نحو کو سپورٹ کرتے ہیں۔ ایک اہم قاعدہ: جو آپ کا نہیں ہے اسے موک نہ کریں — ویلیو آبجیکٹ اور معیاری لائبریریوں کے لیے موک نہ بنائیں۔

// Kotlin میں Mockito کے ساتھ یونٹ ٹیسٹ کی مثال
class OrderServiceTest {

    @Mock
    private lateinit var paymentGateway: PaymentGateway

    @Mock
    private lateinit var userRepository: UserRepository

    private lateinit var orderService: OrderService

    @BeforeEach
    fun init() {
        MockitoAnnotations.openMocks(this)
        orderService = OrderService(paymentGateway, userRepository)
    }

    @Test
    fun processOrder_whenPaymentFails_shouldThrowException() {
        // given
        val user = User(id = 1, balance = 100.0)
        val order = Order(amount = 200.0)
        Mockito.`when`(paymentGateway.charge(any())).thenReturn(false)
        Mockito.`when`(userRepository.findById(1)).thenReturn(user)

        // when & then
        assert Throws<PaymentException> {
            orderService.processOrder(user.id, order)
        }

        // verify
        Mockito.verify(paymentGateway).charge(any())
    }
}

TDD: ٹیسٹ سے چلنے والی ترقی

TDD (Test-Driven Development) ایک طریقہ کار ہے جس میں کوڈ کے نفاذ سے پہلے ٹیسٹ لکھا جاتا ہے۔ "سرخ-سبز-ری فیکٹر" چکر: ایک ٹیسٹ لکھیں جو ناکام ہوتا ہے (سرخ)، ٹیسٹ پاس کرنے کے لیے کم سے کم کوڈ لکھیں (سبز)، رویہ تبدیل کیے بغیر کوڈ کو بہتر بنائیں (ری فیکٹر)۔ TDD اس بات کی ضمانت دیتا ہے کہ تمام کوڈ ٹیسٹ سے ڈھکا ہوا ہے (نافذ کردہ فعالیت کے لیے کوریج = 100%) اور کوڈ قابل ٹیسٹ ہے — اگر کوڈ کا ٹیسٹ کرنا مشکل ہے، تو فن تعمیر کو بہتر کرنے کی ضرورت ہے۔

TDD کے فوائد

IBM (2006-2026، طولانی مطالعہ) کی تحقیق کے مطابق، TDD استعمال کرنے والی ٹیموں میں کوڈ کے بعد ٹیسٹ لکھنے والی ٹیموں کے مقابلے پروڈکشن میں 40-80% کم نقائص پائے جاتے ہیں۔ TDD فن تعمیر کو بھی بہتر بناتا ہے: ڈویلپر نفاذ سے پہلے API ڈیزائن کے بارے میں سوچنے پر مجبور ہوتا ہے، جس سے ڈھیلا جوڑ (loose coupling) اور اعلی ہم آہنگی (high cohesion) پیدا ہوتی ہے۔ ایک اضافی اثر زندہ دستاویزات ہے: ٹیسٹ ماڈیول کے رویے کی ایک تفصیلات کے طور پر کام کرتے ہیں، جو ہمیشہ تازہ ترین رہتی ہیں۔

TDD کب مناسب نہیں ہے؟

TDD ہمیشہ بہترین نہیں ہے۔ UI اجزاء کو الگ کرکے ٹیسٹ کرنا مشکل ہے — ان کے لیے سنیپ شاٹ ٹیسٹ یا بصری ریگریشن ٹیسٹنگ (Percy, Chromatic) زیادہ مؤثر ہیں۔ پروٹوٹائپنگ اور تحقیق (اسپائک سلوشنز) کو ٹیسٹ کی ضرورت نہیں ہوتی۔ بغیر ٹیسٹ کے لیگیسی کوڈ کو TDD کے ذریعے ڈھانپنا مشکل ہے — یہاں پہلے کریکٹرائزیشن ٹیسٹ (وہ ٹیسٹ جو ری فیکٹرنگ سے پہلے موجودہ رویے کو قید کرتے ہیں) کی ضرورت ہے۔ ان صورتوں میں، TDD کو مکمل طور پر ترک نہیں کیا جاتا بلکہ ڈھال لیا جاتا ہے — پورے لیگیسی کوڈ کے لیے نہیں، بلکہ تبدیل شدہ فعالیت کے لیے ٹیسٹ لکھے جاتے ہیں۔

موبائل ایپلیکیشنز میں یونٹ ٹیسٹنگ

موبائل ڈویلپمنٹ کی اپنی خصوصیات ہیں: کاروباری منطق اکثر UI کوڈ (Activity, ViewController, ViewModel) کے ساتھ مل جاتی ہے، جو یونٹ ٹیسٹنگ کو پیچیدہ بناتی ہے۔ بہترین عمل ہے پتلے ویو، موٹے ViewModels: تمام منطق کو UI اجزاء سے علیحدہ کلاسز (UseCase, Repository, ViewModel) میں نکالیں جنہیں ایمولیٹر کے بغیر آسانی سے ٹیسٹ کیا جا سکے۔ Android اور iOS میں مقامی یونٹ ٹیسٹنگ فریم ورک ہیں جو ڈیوائس شروع کیے بغیر JVM/Native پر چلتے ہیں۔

Android پر یونٹ ٹیسٹ (JUnit + Mockito/Robolectric)

Android یونٹ ٹیسٹ ایمولیٹر کے بغیر مقامی JVM پر چلتے ہیں، جو عملدرآمد کی رفتار فراہم کرتے ہیں — ایک عام ٹیسٹ 100ms سے کم لیتا ہے۔ JUnit 5 مرکزی رنر ہے۔ ViewModel ٹیسٹ کے لیے، کوروٹین ٹیسٹ کے لیے kotlinx-coroutines-test اور StateFlow ٹیسٹ کے لیے Turbine استعمال کریں۔ Robolectric شیڈو کلاسز لوڈ کرکے ایمولیٹر کے بغیر Android پر منحصر اجزاء (Context, Resources) کو ٹیسٹ کرنے کی اجازت دیتا ہے۔ Compose ٹیسٹ کے لیے، Compose UI Test استعمال کریں — لیکن یہ UI ٹیسٹ ہیں، یونٹ ٹیسٹ نہیں۔

iOS پر یونٹ ٹیسٹ (XCTest + Quick/Nimble)

iOS یونٹ ٹیسٹ Swift میں XCTest (Xcode میں شامل) کے ساتھ لکھے جاتے ہیں۔ Quick + Nimble زیادہ پڑھنے کے قابل ٹیسٹ (describe/context/it) کے لیے BDD فریم ورک ہیں۔ موکنگ کے لیے، Cuckoo (موک جنریشن) یا SwiftyMocky استعمال کریں۔ Swift پروٹوکول اور ڈیپنڈنسی انجیکشن کو سپورٹ کرتا ہے، جس سے انحصار کو تبدیل کرنا آسان ہو جاتا ہے۔ اہم نکتہ: iOS یونٹ ٹیسٹ حقیقی ڈیوائس پر نہیں، macOS سمیولیٹر پر چلتے ہیں۔ ہارڈویئر خصوصیات (کیمرہ، بلوٹوتھ) کی ضرورت والے ٹیسٹ انٹیگریشن ٹیسٹ ہیں۔

Flutter پر یونٹ ٹیسٹ (flutter_test + Mockito)

Flutter یونٹ ٹیسٹ flutter_test پیکیج استعمال کرتے ہیں اور ایمولیٹر کے بغیر Dart VM پر چلتے ہیں۔ موکنگ کے لیے، کوڈ جنریشن (build_runner) کے ساتھ mockito پیکیج استعمال کریں۔ وجیٹ ٹیسٹ (ایک ہی پیکیج میں) انفرادی وجیٹس کو ٹیسٹ کرتے ہیں لیکن رینڈرنگ کی ضرورت ہوتی ہے اور آہستہ چلتے ہیں — انہیں صرف UI منطق کی تصدیق کے لیے استعمال کریں۔ خالص Dart منطق (ماڈلز، ریپوزٹریز، بلاکس) کو flutter_test درآمد کیے بغیر عام Dart ٹیسٹ کے طور پر ٹیسٹ کیا جاتا ہے۔

// Flutter میں mockito کے ساتھ یونٹ ٹیسٹ کی مثال
import 'package:flutter_test/flutter_test.dart';
import 'package:mockito/mockito.dart';
import 'package:mockito/annotations.dart';

@GenerateMocks([ApiClient])
import 'user_repository_test.mocks.dart';

void main() {
    late MockApiClient mockApi;
    late UserRepository repository;

    setUp(() {
        mockApi = MockApiClient();
        repository = UserRepository(mockApi);
    });

    test('fetchUser returns user when API succeeds', () async {
        // Arrange
        final expectedUser = User(id: 1, name: 'Test');
        when(mockApi.getUser(1))
            .thenAnswer((_) async => expectedUser);

        // Act
        final result = await repository.fetchUser(1);

        // Assert
        expect(result, expectedUser);
        verify(mockApi.getUser(1)).called(1);
    });
}

بہترین طریقے اور عام غلطیاں

مؤثر یونٹ ٹیسٹنگ کے لیے نظم و ضبط کی ضرورت ہے۔ اہم قاعدہ: رویے کا ٹیسٹ کریں، نفاذ کا نہیں۔ ٹیسٹ کو یہ نہیں جاننا چاہیے کہ ماڈیول اندرونی طور پر کیسے نافذ کیا گیا ہے (کون سے پرائیویٹ میتھڈز کس ترتیب سے کال ہوتے ہیں)۔ اگر ٹیسٹ نفاذ سے جڑا ہے، تو یہ ہر ری فیکٹرنگ پر ٹوٹ جاتا ہے اور قدر کھو دیتا ہے۔ ٹیسٹ معاہدے کی تصدیق کرتا ہے: ان پٹ X پر، آؤٹ پٹ Y ہونا چاہیے۔ استثنا اہم کارکردگی والے الگورتھم کے ٹیسٹ ہیں، جہاں کال کی ترتیب اہمیت رکھتی ہے۔

• فی ٹیسٹ ایک تصدیق — ایک منطقی تصدیق کے لیے ایک assert یا متعلقہ asserts کا ایک گروپ
• تکرار سے بچیں — مشترکہ ابتداء کے لیے @BeforeEach / setUp استعمال کریں، مختلف ان پٹ ڈیٹا کے لیے پیرامیٹرائزڈ ٹیسٹ استعمال کریں
• پرائیویٹ میتھڈز کو ٹیسٹ نہ کریں — عوامی API کے ذریعے ٹیسٹ کریں۔ اگر پرائیویٹ میتھڈ ڈھکا نہیں ہے، تو اس کی منطق باہر سے نظر نہیں آتی
• حدی صورتیں ڈھانپیں — خالی مجموعے، null/undefined، منفی اعداد، زیادہ سے زیادہ اقدار
• ٹیسٹ میں Thread.sleep استعمال نہ کریں — یہ ٹیسٹ کو سست اور غیر مستحکم بناتا ہے۔ ٹیسٹ ٹائم آؤٹ اور کوروٹین استعمال کریں

کتنی کوریج کافی سمجھی جاتی ہے؟

100% کوریج ایک ناقابل حصول اور غیر ضروری ہدف ہے۔ Google Testing Blog (2025) کے مطابق، یونٹ ٹیسٹ کے لیے بہترین کوریج کی سطح کوڈ کی 70-80% لائنز ہیں۔ 100% کوریج اکثر گیٹرز، سیٹرز اور کنسٹرکٹرز کو ٹیسٹ کرکے حاصل کی جاتی ہے، جو کوئی قدر نہیں بڑھاتی۔ اہم کاروباری منطق پر توجہ دیں: پیچیدہ حسابات، توثیق، غلطی سے نمٹنا، حدی صورتیں۔ پیمائش کے لیے JaCoCo (Java)، Coverage.py (Python)، Istanbul (JS) استعمال کریں اور CI میں ایک حد مقرر کریں — 60% سے کم کوریج پر بلڈ ناکام۔

CI/CD اور یونٹ ٹیسٹ

یونٹ ٹیسٹ کسی بھی CI/CD پائپ لائن کا پہلا مرحلہ ہیں۔ یہ بلڈ اور ڈیپلائمنٹ سے پہلے، ریپوزٹری میں ہر پش پر چلتے ہیں۔ یونٹ ٹیسٹ سوٹ کا اوسط رن ٹائم 5 منٹ سے زیادہ نہیں ہونا چاہیے — اگر زیادہ ہو، تو ٹیسٹ "تیز" نہیں رہتے اور ڈویلپر انہیں مقامی طور پر چلانا چھوڑ دیتے ہیں۔ ٹیسٹ کو تیز (یونٹ) اور سست (انٹیگریشن) میں تقسیم کریں اور پائپ لائن کے مختلف مراحل میں چلائیں۔ رفتار کے لیے متوازی عملدرآمد اور فیل-فاسٹ استعمال کریں۔